 Thanks. Hello, my name is Andrea Floresco and I will talk about Rust VMM, and how can that help you into building your own custom VMM. So, this is my first time at FOSDM. Well, actually, my second time giving a presentation and I heard that the first thing that you have to do is introduce yourself in case you are wondering. This is a failed attempt at reproducing my GitHub profile page. I'm super excited about the open source. This is my current focus at Amazon where I'm a software development engineer. I'm a maintainer at Firecracker and also a contributor at Rust VMM. But before getting into details about what either of these things are, let me start with a simple analogy. So, let's say that we want to build a motorcycle. The first step is to gather the requirements and getting a pretty clear idea of what we want to build. Next, we will just break it into tasks and thinking about the components that we need for our motorcycle. But then we soon realize that this is actually going to take a lot of time. So, can we use something that already exists? And the answer is yes, because I wouldn't have asked the question otherwise. So, we can use a car. Everybody's using the car. We know that the car is great. People have used it in other projects as well. So, it must be perfect for our use case. Now, the car is too complex. So, we just start removing the components that we do not need. And we soon face a serious problem. So, the motorcycle will fell down. So, we have to add some weight to balance it. Which means that we patch it a bit. We are at the end of our project and we compare what we wanted to build with what we actually built. And we are not really satisfied with the result. So, even though the car was super great, our motorcycle is not ideal. Now, we naturally ask ourselves, is there a better way to build this? And of course there is. Now, we can build it from scratch. But that takes a lot of time. So, moving to the technical side of the talk, this is similar to what CrossVM did about two years ago. Instead of using an existing VMM, they decided to build their own VMM as a lightweight VMM written in Rust. CrossVM runs on top of KVM and it is used for providing application isolation in Chromium OS. Moving a bit in time, about more than one year ago, we decided to build Firecracker. We also wanted a lightweight VMM that can boot very fast and that has a low memory footprint. And that is because we want to build Firecracker for short-lived and multi-tenant workloads. Now, Firecracker was also supposed to run on top of KVM. And we started our design process and we analyzed the options that we have. We decided to go with Rust because it's a system language. It's a language that offers memory safety, concurrency safety, and also it has performance that is similar to modern C++. Now, after some digging, we discovered CrossVM and we decided to start our work from there. Now, even if Firecracker was developed, was started as a fork of CrossVM, the project's almost instantly diverse. And that is because they have really different customer use cases. So CrossVM, as I said, is providing Linux, it's providing isolation for Linux application in Chromium OS, which means that you could potentially run, for example, Photoshop in your Chromebook. And for running Photoshop, it would actually make a whole lot of difference in having features like GPU and PCI. Now, Firecracker is used for some other things. So it is powering AWS Fargate and AWS Lambda. And it is running in a cloud environment at scale, which means that we added features that could make us operate it easily, like metrics. But we also have rate limiting for block devices and for network devices. And we also have a feature by which the guest can query information about the microVM that is running in, which is MMDS. Now, they're different. We talked about it. But still, there are some common virtualization components. So because they are both built on top of KVM, they have the KVM API wrappers. They have block device and network device. So they have a similar implementation of the specification. And because they are both lightweight microVMs, well, VMMs, they have a minimal kernel loader. And there are some other components as well. So basically, if we are going back to the analogy with which I started the presentation, we are now having two motorcycles. But if somebody wants to build a third motorcycle, there is no good way to do that. So basically, they would have to either fork one of the projects or start from scratch. And actually, this is where RazVMM comes into place. And one of the reasons why it exists. RazVMM is an open source project. It started about two months ago. It's very fresh. And it is a place for sharing common virtualization components. If you're wondering why would you actually want that, well, the first obvious reason is that it would be actually very easy for a firecracker and KVM to share common virtualization code. But since we are here, and I can ask you why would you actually care about that, because maybe you wouldn't, unless you were working for one of the projects. And now the answer is you should care about it because RazVMM is going to do much more. So with RazVMM, you can create your custom VMMs. And that is because it is taught with modularity and testing in mind. So for example, let's say that you want to build a VMM that is for Kubernetes. That means that this VMM is going to be fully compatible with the runtime interface. And also it will have features like memory hotplug and CPU hotplug and host file system sharing, which is something that, for example, in Firecracker, we don't have a really good use case to add it. So far there are some people that are involved. We aren't many people. This is a call for you to get involved as well. People have contributed code. People have participated in discussions. We have a feedback process by which we are adding components into RazVMM so people have also provided reviews. If you want to help, it is as simple as becoming a RazVMM member on GitHub. You just have to open a new issue in the community repository. Then if you want to participate in the discussions, there is an email list. And if you have an idea about the component, that could be a good fit for RazVMM. You can write it and then open a review request and people will look at it. Now, you might think that the talk is over, but it's not. And there are two reasons for that. So one is I just added the slides two days ago. And the other reason is that we are going to talk about what's next. So what is in the future? There are some discussions ongoing about adding the host user, user space implementation for the host in RazVMM. Then there are also some discussions around porting QMU components which I actually find very interesting. But the future is not set in stone, and it is an ideal time for you to come and decide with us. The talk is still not over. And we are going to go over an example of a VMM that you can build with components of RazVMM. And this slide is actually here because with the current stage of RazVMM, you can't really build anything because we don't have enough crates there or components. So we are going to build a minimal VMM. It's not exactly minimal. It is more to prove a point of the structure of RazVMM. So our VMM is going to run on top of KVM. So we will need some KVM wrappers. Then we will need a kernel loader, a block device for our root file system and the user interface. The first thing that we are going to do is write the VMM user interface. This is basically the place where an external client, let's call it, is going to configure the VMM that wants to run. Now, next we are going to look at the future RazVMM components. So before getting into details about what these things are, let's talk a bit about structure. Each box on the right side of the screen, it's a crate or a package. In Raz packages are called crates. So that was my first slide sharing crates, virtualization crates. Now, each crate can have zero, one, or many modules. And this is, for example, the vertio devices, which has a block device, a net, a viscoc and a serial, each structure in a module. Now, there is an interesting feature about that Rust. There is an interesting thing that Rust helps us with now. Instead of, for example, you want to use just the block device. And instead of importing all the code, you can import only the block device by using features, which basically means that it's actually just conditional compiling. Now, let's get them one by one. So KVM bindings is actually auto-generated code with binding. It is a Rust for in function interface to the KVM headers. But these are not very useful by themselves because it basically just defines and structures. Now, on top of that, we can build a KVM wrapper, which actually has implementation wrappers over IOCTLs, KVM IOCTLs, which can help us in doing stuff like opening def KVM, creating a VM, also creating VCPUs, and so on. Next, we have vertio bindings, which are similar to KVM only that they are auto-generating from vertio headers. And we have the implementation for the vertio specification in the vertio devices that I talked about earlier. Next, we have a kernel loader. The kernel loader is minimal. It just loads the kernel image in the guest memory. A rate limiter that can be applied on the vertio devices to limit operation per seconds and the bandwidth, and also the V-host user. Now, we said that our VMM is going to be minimal, so we are just going to select some of these. And because these components are actually independent in some way, we can just dump them into our VMM and everything works. We will have to also add a VMM glue that is basically responsible for interacting with the VMMs and also making the connection to the VMM user interface so people can actually start VMS with our minimal VMM. Now, there is only one thing to do. We have to profit. And that was all. This is really the end of the talk. The first link you have is the RazVMM organization on GitHub. Next, if you click the link on this slide, the second link, it will take you to the subscribe page for the RazVMM email list. And the last one is my email address, so if you have any questions that you do not want to ask now, you can send me an email and I will be more than happy to help you. Thank you. So the question was if on the first, do you mean this one? Yes. So the question was whether these crates are already available on crates.io. So the thing is that the only thing that we actually have in RazVMM now is the crate KVM bindings. This is already available on crates.io as well, and we are using it in Firecrackers, so it's working. All the others, we have to add them. So the follow-up question was if we reserve the names, no, we didn't. You should. And the answer was we should. Yeah, so the question was if we plan to add arm support. So I started with KVM bindings. It has support for arms, so the bindings are generated for arm as well. And the plan is actually for the craze that I'm adding there to have support for both x86 and arm, and I'm actually working with one of my colleagues to do this for the KVM wrappers. What? Sorry. Okay, so I don't have... The question is if we are going to add support for other architectures as well. I can't do that by myself obviously because I'm 26 and don't actually know all those architectures by name. Yes. Yeah, this is different. Well, because you can conditionally compile everything, that means that you can add support for many platforms and it should be okay for most people because if they don't want your code, they will just not pull it in. Yeah. It is a common foundation. Oh, so the question was if this is a common foundation and if we are working with KVM. So I just want to make something clear. This is not Firecracker, so this is not a product owned by a company and it's not a product of its own. It's really just the place to share common virtualization components between many VMMs so we can build them in the same way. Yeah. The question is if we can create non-rust VMM on top of it and I don't really know how to answer that question. Probably for languages that allow you to call a code that is not rust, maybe. I really don't know how to answer that, sorry. So the question was if we are going to replace QMU components with components from Rust VMM and there is actually some discussion about it on the Rust VMM email list, you should join it as well so you can participate in the discussion so I think that's the plan. Yeah, that's it.