WEBVTT 00:00.000 --> 00:12.960 Thank you. Hello everyone. Thanks for showing up here and joining us five track here. I'm 00:12.960 --> 00:19.760 rushing from Eastcast, Institute of Software, Chinese Academy of Sciences. Today, I would like 00:19.760 --> 00:27.440 to talk about share the status of the progress we made in expanding the software, virtual 00:27.440 --> 00:34.440 software, especially their software, that's H-Extension based software ecosystem. 00:34.440 --> 00:43.440 So first, I will start introducing the status of RIS5 hardware. It's explaining the 00:43.440 --> 00:51.440 very reason why the RIS5 virtualization software stack is in a way underdeveloped compared 00:51.440 --> 01:03.440 to the X86 and RMS. So virtualization software now has a very wide audience nowadays. 01:03.440 --> 01:10.440 They have proven themselves a very important software stack to both study and industry. 01:10.440 --> 01:17.940 But abstracting and virtualizing the essential physical components of a computer, virtualization 01:17.940 --> 01:24.940 software enables dividing the resources of physical machines to a bunch of virtual machines. 01:24.940 --> 01:31.940 Effectively making use of the computer resources, computing resources of physical machines. 01:31.940 --> 01:42.940 This illustration here is showing the basic logic of a typical type 2 advisor, which is also our focus today. 01:42.940 --> 01:52.940 The H-Extension for RIS5 is like the VTX of Intel and the V of AMD to X86. 01:52.940 --> 02:03.940 And virtualization extension to ARM. H-Extension of RIS5 is ratified and put into RVA23 standard. 02:04.940 --> 02:13.940 That's just not yet made available, especially when a advanced interrupt architecture is considered as concerns. 02:13.940 --> 02:25.940 So as of now, we can't get hold on SLC's debt is capable of running the virtualization software stack. 02:25.940 --> 02:38.940 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. 02:38.940 --> 02:45.940 This case, Institute of Software, Chinese Academy of Sciences is a non-profit Institute. 02:45.940 --> 02:51.940 We are dedicated to build a prosperous software ecosystem for RIS5. 02:51.940 --> 02:55.940 So our primary objectives are three folks. 02:55.940 --> 02:59.940 We need our works to be hardware verified. 02:59.940 --> 03:07.940 We've developed this software into EMU for emulation environment, because we don't have any other options for now. 03:07.940 --> 03:11.940 And that's definitely not the end of it. 03:11.940 --> 03:16.940 So we work closely with RIS5 hardware vendors like SpaceMid. 03:16.940 --> 03:35.940 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. 03:35.940 --> 03:45.940 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. 03:45.940 --> 03:55.940 Of different distros as much as possible, including by porting, maintaining and packaging. 03:55.940 --> 04:14.940 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. 04:15.940 --> 04:20.940 Our team spares no effort making open oil at RIS5. 04:20.940 --> 04:28.940 The most cutting-edge verification distribution, especially in virtualization and cloud native software stack. 04:28.940 --> 04:38.940 Speaking of virtualization software, there remains a problem of choosing the distribution of host or guest distros. 04:39.940 --> 04:49.940 The upper oil distribution has dedicated to version 6.6 kernel, and going to stick to it in several years ahead. 04:49.940 --> 05:05.940 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. 05:05.940 --> 05:11.940 Well, keep supporting and contributing works to upstream communities. 05:11.940 --> 05:17.940 Concerns, packaging software in open oil RIS5 distribution. 05:17.940 --> 05:23.940 This picture is from open oil build service abbreviated for EBS. 05:23.940 --> 05:31.940 The emerging RIS5 architecture is catching up with the other two predecessors. 05:32.940 --> 05:39.940 Then, I'm going to show the roadmap we have planned for this year. 05:39.940 --> 05:52.940 So, in the very first stage, we want to explore a button up, usable, maintainable, and a dependable software stack out RIS5 platforms. 05:52.940 --> 05:59.940 So, from the button up, basically, we are needed to work on upper oil distribution. 05:59.940 --> 06:07.940 So, we are back porting features like AA drivers to the version of kernel that upper oil concerns to. 06:07.940 --> 06:13.940 And from that, we work out RIS5 architecture. 06:13.940 --> 06:20.940 At least the basic architecture depends, dependant creates. 06:20.940 --> 06:30.940 On top of that, we have chosen cloud advisor as the advisor we need to support in stage 1. 06:30.940 --> 06:36.940 To provide virtualization functionalities for software depends on it. 06:36.940 --> 06:47.940 The way it integrates into cloud containers supports supporting secure containers on RIS5 architecture. 06:47.940 --> 06:56.940 So, in the next stage, we want to build a fully supported, reliable and prosperous virtualization software ecosystem of RIS5. 06:56.940 --> 07:07.940 Enabling RIS5 to compete with the other two RX86 and both virtualization and cloud native software ecosystem. 07:07.940 --> 07:14.940 At least the items listed in our roadmap are fully supported. 07:14.940 --> 07:23.940 Following that roadmap, we have achieved some milestones in these communities by far. 07:23.940 --> 07:36.940 We initiated this work in April, 2024, while we were trying to support a stratavet to work on RIS5 64bit architecture. 07:36.940 --> 07:48.940 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. 07:48.940 --> 07:57.940 We started in the middle of this software stack and we realized that when we need to do this button up, 07:57.940 --> 08:04.940 simply because upstream communities won't accept code in our private repost that pretty much makes sense. 08:04.940 --> 08:11.940 So, for stratavet and the cloud hypervisor, there's two communities to accept our work. 08:11.940 --> 08:18.940 RIS5 needs to support RIS5 and release this code in advance. 08:18.940 --> 08:27.940 Here is again showing the whole process of enabling five of RIS5 in crates to work on RIS5 architecture. 08:27.940 --> 08:33.940 This picture is next that I will try to make it clearer. 08:33.940 --> 08:48.940 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. 08:48.940 --> 08:53.940 On top of it, the first one is RIS5M container. 08:53.940 --> 09:02.940 This report is responsible for producing the images used to run CIs in RIS5 and community. 09:02.940 --> 09:15.940 They build images originally for X86, S64 and ARM64 and we need it to build images for RIS5. 09:15.940 --> 09:36.940 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. 09:36.940 --> 09:44.940 Without the CIs that dedicated to take care of RIS5 code, the community cannot merge our code. 09:44.940 --> 09:50.940 So, we started to explore a way of enabling RIS5CI in RIS5M community. 09:50.940 --> 10:11.940 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. 10:11.940 --> 10:19.940 So, we have put up three proposals to try and address this question. 10:19.940 --> 10:39.940 Eventually, we have settled as this is my third proposal of RIS5CI, typically for the software that need KVM devices, a RIS564 KVM devices. 10:39.940 --> 10:49.940 Which is designed to be used, until we get hold on real hardware that is capable of running these tests. 10:49.940 --> 10:56.940 RIS5M community uses GitHub action runer only in RIS5M container repo. 10:56.940 --> 11:04.940 This repo has less traffic and is used to build container images for different architectures as I mentioned before. 11:04.940 --> 11:11.940 And these images would be used for other repos to run their CIs. 11:11.940 --> 11:21.940 The community use build kits in the rest of RIS5M workflows are executed in images built by RIS5M container. 11:21.940 --> 11:31.940 As of now, many of its creates are now RIS5 support and released, which enables us to work on a higher level. 11:31.940 --> 11:36.940 The next hypervisor level. 11:36.940 --> 11:46.940 This is a dependers' graph of clocked-habilizer, which shows the intersection of creates of clocked-habilizer and RIS5M. 11:46.940 --> 11:53.940 Green crates are from RIS5M community and the others are clocked-habilizer natives. 11:53.940 --> 11:56.940 So let's abstract this a bit. 11:56.940 --> 12:04.940 This picture does not necessarily suggest all the crates showing here, or components showing here. 12:04.940 --> 12:07.940 Listed here are architecture dependent. 12:07.940 --> 12:12.940 I draw this architecture of you according to my understanding of clocked-habilizer. 12:12.940 --> 12:20.940 So now many of our works in supporting RIS5 are already upstream. 12:20.940 --> 12:31.940 So clocked-habilizer in my fork is capable of direct-booting RIS5 Linux now. 12:31.940 --> 12:40.940 So here again, CI for H extension based H extension basis software like clocked-habilizer and RIS5M community. 12:40.940 --> 12:43.940 I guess, need special design anyway. 12:43.940 --> 12:49.940 We adopted similar approach used in RIS5M community. 12:49.940 --> 12:57.940 In the process of upstream-lit RIS5 support to this clocked-habilizer community, we've faced it exactly. 12:57.940 --> 13:05.940 The same problem we encountered in supporting RIS5M for RIS5 architecture. 13:05.940 --> 13:10.940 We don't have actual hardware capable of running these CI's. 13:10.940 --> 13:16.940 So here's a big difference between clocked-habilizer and RIS5M community. 13:16.940 --> 13:21.940 They only use GitHub actually run this and use it directly. 13:21.940 --> 13:30.940 So we provide a physical 9950X machine which has a relatively high base frequency. 13:30.940 --> 13:35.940 We're hoping to speed up the full emulation process. 13:35.940 --> 13:45.940 So we provide this physical machine to the community dedicated to handle RIS5 CI's. 13:45.940 --> 13:58.940 So Strathlet RIS5 MicrowaveM support is completed last year and released along with OppoEuler to 2403 LTSSP1. 13:59.940 --> 14:05.940 This works for Verified on SpaceMed X100 FPGA environment. 14:05.940 --> 14:17.940 Here is a video showing the process we're verifying the Strathlet RIS5 work on the Android FPGA. 14:17.940 --> 14:26.940 So first we catch the CPU info to distinguish where in the host or guest. 14:27.940 --> 14:34.940 This is the quick way to use to boot a VM use Strathlet. 14:34.940 --> 14:38.940 Now the VM is starting up. 14:38.940 --> 14:52.940 I can see from the analog that AA components, MSSC and APIC is in the log. 14:53.940 --> 15:02.940 So this is the image we put is a very basic OppoEuler distribution. 15:02.940 --> 15:11.940 And judging by the output of CPU info, it's now in a virtual machine. 15:11.940 --> 15:21.940 And the content of the device training we are using in a advanced interrupt architecture for this virtual machine. 15:21.940 --> 15:28.940 So that's it. 15:28.940 --> 15:36.940 We have now successfully launched V3.13.0 code containers on OppoEuler RIS5. 15:36.940 --> 15:46.940 24.03 LTSSP1 with its gop wrong time and the Qemu V8.2.0 as its hypervisor. 15:46.940 --> 15:57.940 This is a log showing the way launching a secure container in RIS5 environment. 15:57.940 --> 16:00.940 I have prepared a demo for this. 16:00.940 --> 16:05.940 I only need to switch to my computer to illustrate it. 16:16.940 --> 16:42.940 Oh, this resolution. 16:42.940 --> 17:03.940 This was going to go back in a bit. 17:03.940 --> 17:18.940 Nope. 17:18.940 --> 17:42.940 I'm going to use T-max, so I want to display as much content as possible. 17:42.940 --> 17:57.940 Okay. 17:57.940 --> 18:25.940 So this is an OppoEuler RIS5. 18:25.940 --> 18:41.940 24.23 LTSSP1 distribution. 18:41.940 --> 18:51.940 I don't know why my terminal is not responding to my input. 19:11.940 --> 19:23.940 Okay, this one is working. 19:23.940 --> 19:44.940 So that's the information of the distribution we are using. 19:44.940 --> 20:03.940 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. 20:03.940 --> 20:18.940 Okay, let's start a continuity here. 20:18.940 --> 20:33.940 Okay, this is the common use of continuous to run a secure container. 20:33.940 --> 20:43.940 This is a continuity is responding to the request and it's booting a qemu vetch machine. 20:43.940 --> 20:51.940 This is slow because we are running this on a qemu environment. 20:51.940 --> 20:57.940 And we have the prompt. 20:57.940 --> 21:01.940 This is inside the container. 21:01.940 --> 21:13.940 So basically we have enabled code containers and lists in upper oriented distribution and we are now upstreaming all the works. 21:13.940 --> 21:30.940 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. 21:30.940 --> 21:38.940 And my roadmap of our team and the works we are doing in different communities. 21:38.940 --> 21:44.940 Yes, and we also take active parsing RIS5 international and RIS project. 21:44.940 --> 21:51.940 I have documented all the works. 21:51.940 --> 21:58.940 And they give smaller. 21:58.940 --> 22:07.940 So we can, you can acquire the information and the status in the RIS project. 22:07.940 --> 22:16.940 In the kernel and virtualization working group, I have documented all the information works we have done. 22:16.940 --> 22:26.940 We recorded all the PRs links to each work I mentioned in my presentation. 22:26.940 --> 22:29.940 So thanks for listening. 22:29.940 --> 22:32.940 That's all of my talk. 22:32.940 --> 22:37.940 Thank you. 22:37.940 --> 22:47.940 We have a couple minutes for questions. 22:47.940 --> 22:49.940 So my question is that. 22:49.940 --> 22:54.940 So this demo you showed on kemu environment, right. 22:54.940 --> 23:02.940 But you also mentioned in your slide that you also verified it on the. 23:02.940 --> 23:08.940 It's an X100 space MIT FPGA also. 23:08.940 --> 23:10.940 Yes, right. 23:10.940 --> 23:22.940 And so both the hypervisor extension implementation by them or on kemu, you can get your virtualization stack running. 23:22.940 --> 23:23.940 Yes. 23:23.940 --> 23:25.940 Thank you. 23:32.940 --> 23:40.940 Hello. 23:40.940 --> 23:41.940 Hello. 23:41.940 --> 23:47.940 I have tried the Linux kernel 6.6 with this file and it's lagging a lot. 23:47.940 --> 23:57.940 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. 23:57.940 --> 24:00.940 So are you going to stick with 6.6? 24:01.940 --> 24:03.940 That's not the decision I made. 24:03.940 --> 24:05.940 I have to do it. 24:05.940 --> 24:06.940 Wait. 24:06.940 --> 24:08.940 Consent to 6.6 kernel. 24:08.940 --> 24:10.940 It's managed. 24:18.940 --> 24:19.940 Right. 24:19.940 --> 24:20.940 Thank you.