Thank you. Hello everyone. Thanks for showing up here and joining us five track here. I'm
rushing from Eastcast, Institute of Software, Chinese Academy of Sciences. Today, I would like
to talk about share the status of the progress we made in expanding the software, virtual
software, especially their software, that's H-Extension based software ecosystem.
So first, I will start introducing the status of RIS5 hardware. It's explaining the
very reason why the RIS5 virtualization software stack is in a way underdeveloped compared
to the X86 and RMS. So virtualization software now has a very wide audience nowadays.
They have proven themselves a very important software stack to both study and industry.
But abstracting and virtualizing the essential physical components of a computer, virtualization
software enables dividing the resources of physical machines to a bunch of virtual machines.
Effectively making use of the computer resources, computing resources of physical machines.
This illustration here is showing the basic logic of a typical type 2 advisor, which is also our focus today.
The H-Extension for RIS5 is like the VTX of Intel and the V of AMD to X86.
And virtualization extension to ARM. H-Extension of RIS5 is ratified and put into RVA23 standard.
That's just not yet made available, especially when a advanced interrupt architecture is considered as concerns.
So as of now, we can't get hold on SLC's debt is capable of running the virtualization software stack.
So the next section is about claiming our objectives, what we want to achieve throughout the works we have done and planned to do in the future.
This case, Institute of Software, Chinese Academy of Sciences is a non-profit Institute.
We are dedicated to build a prosperous software ecosystem for RIS5.
So our primary objectives are three folks.
We need our works to be hardware verified.
We've developed this software into EMU for emulation environment, because we don't have any other options for now.
And that's definitely not the end of it.
So we work closely with RIS5 hardware vendors like SpaceMid.
Now, in computing and the shell shell, we use whatever the environment they provided to us to like FPGA environment, Qemu and Extras to verify the works we have done and address the problems encountered along with the process.
Our work is open-source, that's why we've followed up String First Role in hoping to expand the area of benefit and trying to shift to the burdens.
Of different distros as much as possible, including by porting, maintaining and packaging.
What we want to achieve at this stage is to explore a secure container solution during the process, providing RIS5 with that software stack to enable it of supporting, running secure containers.
Our team spares no effort making open oil at RIS5.
The most cutting-edge verification distribution, especially in virtualization and cloud native software stack.
Speaking of virtualization software, there remains a problem of choosing the distribution of host or guest distros.
The upper oil distribution has dedicated to version 6.6 kernel, and going to stick to it in several years ahead.
Unfortunately, as of RIS5, there are a lot of features missing in 6.6 kernel, not with our back porting, maintaining and verifying the features we need to be present and working our upper oil KLK6.6 kernel.
Well, keep supporting and contributing works to upstream communities.
Concerns, packaging software in open oil RIS5 distribution.
This picture is from open oil build service abbreviated for EBS.
The emerging RIS5 architecture is catching up with the other two predecessors.
Then, I'm going to show the roadmap we have planned for this year.
So, in the very first stage, we want to explore a button up, usable, maintainable, and a dependable software stack out RIS5 platforms.
So, from the button up, basically, we are needed to work on upper oil distribution.
So, we are back porting features like AA drivers to the version of kernel that upper oil concerns to.
And from that, we work out RIS5 architecture.
At least the basic architecture depends, dependant creates.
On top of that, we have chosen cloud advisor as the advisor we need to support in stage 1.
To provide virtualization functionalities for software depends on it.
The way it integrates into cloud containers supports supporting secure containers on RIS5 architecture.
So, in the next stage, we want to build a fully supported, reliable and prosperous virtualization software ecosystem of RIS5.
Enabling RIS5 to compete with the other two RX86 and both virtualization and cloud native software ecosystem.
At least the items listed in our roadmap are fully supported.
Following that roadmap, we have achieved some milestones in these communities by far.
We initiated this work in April, 2024, while we were trying to support a stratavet to work on RIS5 64bit architecture.
We found that KVM bindings and KVM out to the two crates from RIS5 in community need to be supported before stratavet could be pushed forward.
We started in the middle of this software stack and we realized that when we need to do this button up,
simply because upstream communities won't accept code in our private repost that pretty much makes sense.
So, for stratavet and the cloud hypervisor, there's two communities to accept our work.
RIS5 needs to support RIS5 and release this code in advance.
Here is again showing the whole process of enabling five of RIS5 in crates to work on RIS5 architecture.
This picture is next that I will try to make it clearer.
So, in the middle of this picture that's showing the KVM bindings, which is great, provides FFIs to KVM APIs, which is very essential of the RIS5M community.
On top of it, the first one is RIS5M container.
This report is responsible for producing the images used to run CIs in RIS5 and community.
They build images originally for X86, S64 and ARM64 and we need it to build images for RIS5.
So, because C from this gant we initially started, we worked out KVM bindings in April 2024, but it's not merged because community lacks the CIs for it.
Without the CIs that dedicated to take care of RIS5 code, the community cannot merge our code.
So, we started to explore a way of enabling RIS5CI in RIS5M community.
Here comes the problem that we don't have actual hardware that is capable of running the RIS5M CIs, because it needs a RIS564 dev KVM device to be present in the environment.
So, we have put up three proposals to try and address this question.
Eventually, we have settled as this is my third proposal of RIS5CI, typically for the software that need KVM devices, a RIS564 KVM devices.
Which is designed to be used, until we get hold on real hardware that is capable of running these tests.
RIS5M community uses GitHub action runer only in RIS5M container repo.
This repo has less traffic and is used to build container images for different architectures as I mentioned before.
And these images would be used for other repos to run their CIs.
The community use build kits in the rest of RIS5M workflows are executed in images built by RIS5M container.
As of now, many of its creates are now RIS5 support and released, which enables us to work on a higher level.
The next hypervisor level.
This is a dependers' graph of clocked-habilizer, which shows the intersection of creates of clocked-habilizer and RIS5M.
Green crates are from RIS5M community and the others are clocked-habilizer natives.
So let's abstract this a bit.
This picture does not necessarily suggest all the crates showing here, or components showing here.
Listed here are architecture dependent.
I draw this architecture of you according to my understanding of clocked-habilizer.
So now many of our works in supporting RIS5 are already upstream.
So clocked-habilizer in my fork is capable of direct-booting RIS5 Linux now.
So here again, CI for H extension based H extension basis software like clocked-habilizer and RIS5M community.
I guess, need special design anyway.
We adopted similar approach used in RIS5M community.
In the process of upstream-lit RIS5 support to this clocked-habilizer community, we've faced it exactly.
The same problem we encountered in supporting RIS5M for RIS5 architecture.
We don't have actual hardware capable of running these CI's.
So here's a big difference between clocked-habilizer and RIS5M community.
They only use GitHub actually run this and use it directly.
So we provide a physical 9950X machine which has a relatively high base frequency.
We're hoping to speed up the full emulation process.
So we provide this physical machine to the community dedicated to handle RIS5 CI's.
So Strathlet RIS5 MicrowaveM support is completed last year and released along with OppoEuler to 2403 LTSSP1.
This works for Verified on SpaceMed X100 FPGA environment.
Here is a video showing the process we're verifying the Strathlet RIS5 work on the Android FPGA.
So first we catch the CPU info to distinguish where in the host or guest.
This is the quick way to use to boot a VM use Strathlet.
Now the VM is starting up.
I can see from the analog that AA components, MSSC and APIC is in the log.
So this is the image we put is a very basic OppoEuler distribution.
And judging by the output of CPU info, it's now in a virtual machine.
And the content of the device training we are using in a advanced interrupt architecture for this virtual machine.
So that's it.
We have now successfully launched V3.13.0 code containers on OppoEuler RIS5.
24.03 LTSSP1 with its gop wrong time and the Qemu V8.2.0 as its hypervisor.
This is a log showing the way launching a secure container in RIS5 environment.
I have prepared a demo for this.
I only need to switch to my computer to illustrate it.
Oh, this resolution.
This was going to go back in a bit.
Nope.
I'm going to use T-max, so I want to display as much content as possible.
Okay.
So this is an OppoEuler RIS5.
24.23 LTSSP1 distribution.
I don't know why my terminal is not responding to my input.
Okay, this one is working.
So that's the information of the distribution we are using.
I mentioned before we have dedicated to 6.6 kernel by using it in several years ahead and now I'm going to use T-max to multiple windows.
Okay, let's start a continuity here.
Okay, this is the common use of continuous to run a secure container.
This is a continuity is responding to the request and it's booting a qemu vetch machine.
This is slow because we are running this on a qemu environment.
And we have the prompt.
This is inside the container.
So basically we have enabled code containers and lists in upper oriented distribution and we are now upstreaming all the works.
So besides this, I have a roadmap in kind of continuous community showing the works we are doing for enabling kind of continuous on RIS5 architecture.
And my roadmap of our team and the works we are doing in different communities.
Yes, and we also take active parsing RIS5 international and RIS project.
I have documented all the works.
And they give smaller.
So we can, you can acquire the information and the status in the RIS project.
In the kernel and virtualization working group, I have documented all the information works we have done.
We recorded all the PRs links to each work I mentioned in my presentation.
So thanks for listening.
That's all of my talk.
Thank you.
We have a couple minutes for questions.
So my question is that.
So this demo you showed on kemu environment, right.
But you also mentioned in your slide that you also verified it on the.
It's an X100 space MIT FPGA also.
Yes, right.
And so both the hypervisor extension implementation by them or on kemu, you can get your virtualization stack running.
Yes.
Thank you.
Hello.
I have tried the Linux kernel 6.6 with this file and it's lagging a lot.
So I think it's going to be a good adventure and not the work to, you know, get batches from the more recent versions of the kernel.
So are you going to stick with 6.6?
That's not the decision I made.
I have to do it.
Wait.
Consent to 6.6 kernel.
It's managed.
Right.
Thank you.