Okay, welcome everyone. I'm Stefan Agarzarella and today I will talk about what we are doing in
Rustvmm. This talk was prepared together with Rohin and Patrick that I would like to thank,
but unfortunately, they cannot be here, so I will try to cover also their part. So, before
going into the details, let's start what is Rustvmm. I don't know if you know about it, but anyway,
we are an open source project that would like to provide
set of virtualization components that people can use to build custom virtual machine monitors or
hypervisor. So, we don't provide any VMMams or hypervisor. We just provide the building blocks
that people can use to build them. And why do Rustvmm? Because we want to reduce code
duplication. We don't want to, for example, implement virtual device in every hypervisor. So,
the idea is just to provide you, okay, this is the implementation of virtual device. You can use it
as a, how you want. We also want to faster a bit the development. So, we are several people
from different projects, from different companies, try to collaborate to provide this components.
We are also trying to focus on security and stability. And, of course, we want to provide a clean
interface because we want to, I mean, we are collaborating with different projects.
I left here the links to our mailing list and Slack channel. If you want to join,
you are really, really welcome. These are the set of repositories that contains Rustvm
creates that we develop. So, essentially, we provide
wrappers for KVM hypervxan. We provide a Linux loader. If your VMMm want to load Linux directly
in your guest, we provide some resource management crates, VM allocator, mainly for MMI
address, IDs, that kind of things. And VMMamory, which is one of our core crate, used by, for example,
all the device emulation, because it is the abstraction of the VMMamory. So, we use that
crate to access the memory in the device emulation, for example. And, about the device, we provide
vertio, of course. We have set of crates for bird cues and also for some vertio devices.
And, then, we also have crates for vhost, vhost user and vdpa. And, our, we also have a lot of
vhost user devices. We will see later which one. We provide wrappers for vfiu and also a little
set of legacy devices like serial port or real time clock. And, we have a couple of repo for our
ecosystem like the CI, because we would like to keep our CI consistent by all of the repos.
So, we have a crate, I mean, repo for our CI and the container that runs all of our tests.
About adoption, we are our user. The first one I would like to mention is firecracker, because
Roth VMMam essentially started with firecracker guys. And, firecracker is a lightweight VMMam
that runs a very lightweight VMs called micro VMs. And, another one is cloud vapor
vital, which is fully based on Rust VMMam crates. This is a more general VMMam that runs
bigger workloads on cloud environment. Then, we have a Libkiran developed by Michael Lixergeur,
which is also a lightweight VM, but extremely lightweight that you can even use in your application
because it's a dynamic library that allows you to run custom process in a very lightweight
VM inside a custom-minded Linux kernel. And, so, if you want to partially isolate a process,
you can use this library in your application. Another user is the Dragon Bolt Sandbox provided
by the Kata Container Community, which is also based on Rust VMMam crates.
These are other projects, not really VMMams, but also in the virtualization
component, virtualization workspace, via user devices. We have a lot of via user devices
that we provide in Rust VMMam, but also others like Vertaier FSD, which is external project,
but they use our crates. Another interesting tool is IMAGA, from Michael Lixergeur,
which provide access to VM disk images, like Tukup2 images. Another one that I found is the VMMaxac,
which it's a common line interface tool that should be able to run single common in a really
draw-away VM. So, if you want to start something in a isolated environment, this could be
the right tool to use. And, I found also this Dragonfly image service called Nages,
that use the Providals, Vertaier FSD, Vertaier FSD protocol, and they do that using our crates,
using Rust VMMam crates. Another two project I would like to mention, because they mentioned us
in how are in there, read me. Essentially, one is Cross VM, and I'd like to say that
part of our code is based on Cross VM, which is one of the first VMMam implemented in Rust.
And now, they seem to open to use a Tukup3 in Rust VMMam, and we are also really open to
welcome them. It could be nice to collaborate together. Another one is more recently
VMMam from Microsoft, which is open VMMam, which is mainly for confidential computing,
and they also mention our work on VMMam staff, and they hope to find a way to collaborate.
We hope to say, maybe in the future, we will be able to collaborate.
Okay, about our crates. So, what we support, what architecture we support? We mainly support
86 and R64. We are working on risk-fi, and I have a couple of slides from Rohin, which did the
great work on that. About operating system, of course, Linux and KVM. We also support Windows in
some crates, and we started to, especially for VOS users, we started to extend the support on any
other POS system. I talked about it last year, here in FOS them, where I have a slide later.
So, yeah, about VOS users, if you're interested, I will talk more about VOS users in the next
talk, in less than one hour, should be, yeah, where I talk more about VOS. But essentially,
VOS users is a way to do device emulation in an external process. In another user space process,
instead of the VMM, mainly for security, but also for flexibility. Because, for example, in KVM,
which, I mean, the spec is in KVM, because the KVM community come up with the VOS user.
But it's so generic that you can implement, in any way, in this case, in Rust VMM,
we are implementing a lot of VOS user device, that you can use with KVM, with cloud vapor
with any VMM that support a VOS user protocol, where we call front end the VM,
which is the one that provide access to the birdcuse, and we call back end the device essentially.
The one that consumes the birdcuse. And it's a bit generic. The only components that
VOS user protocol use are a unique domain socket, because it's also able to move file
descriptor around, and then we use the file descriptor passing feature of VOS user. Unix domains
socket to share the memory, mainly the guest memory, and also to set up some
notification system. We use a eventfD on Linux, for example, or pipes on other operating system.
Yeah, about what we provide about VOS user, in Rust VMM, we have a VOS crate,
which provides all the wrappers for VDPA, VOS, and VOS user. And then we have a VOS
user back end trade, which is a framework to implement VOS user devices. And in this crate,
we provide a demon control object to start and stop the device, essentially a trade to handle
the VOS user control messages, and also a trade to access the birdcuse. And as I mentioned,
in the Rust VMM project, we provide several devices, several birthday or devices, like
can control scasysound, visoc, at least all of them here, and if you're interested in the
Zeling. And also we have an external project called VirtiFSD, which is fully based on our Rust VMM
crate and use exactly VOS user back end to implement a VOS device as a VOS user device.
What we did in the last years, about VirtiFSD. So we started to support VOS 6, a bit more,
I mean, we started with Linux, of course, and then we tried to support any VOS 6 system for Vhost.
Last year we also started to do formal verification of VirtiFSD devices. VirtiFSD is an open
specification, and with Google Summit of CodeProject, we started to put some kind of formal
verification to check that our VirtiFSD devices follow the spec. And then we added a couple of
new support for VOS user messages, some classes written writer to parse better the VirtiFSD
descriptors. We started to support the VirtiFSD, which is another essentially VirtiO provides
two VirtiFSD formats, split and part, and split is the, we can say the default one, the part
that is the new one that we started to support recently. And we also started to support live
migration for VOS user, and this is implemented in VirtiFSD right now. And also we added
support for shared object and shared memory, which is mainly for devices like video, GPU,
video, video, video, video, video, video, and I mentioned that a couple of these new features
were developed by GSox student. So last year we did two successful project, one to support
MacRasson BSD, essentially for VOS user in Rust VMM, and that was done by Wanyu Wang,
mentor by Hermann Holywell and myself, and Matias, another microly, mentor to Zeta Priya to essentially
put the formal verification in our devices using Kani. And this year Kimo will apply the
already applied. I mean we are usually we do our Google summer code project under the Kimo umbrella,
and they want to like to thanks the Kimo community for that. This year Kimo will apply again,
Google will communicate, I don't know, I think in a couple of weeks, if it is accepted or not,
if yes, one of the projects is also related to Rust VMM, which is this one to implement a
virtual real-time cloud device as a VOS user device in Rust VMM, and if you are interested,
feel free to contact Matias franchise, because we would like to do this new device.
Other things we did in VMM, which is one of our core crate. This last year was to support
VMM. We started to support VMM. There is also a working progress mainly by Patrick,
to try to make our crate feature additive. Essentially, we have a feature to support exam,
which is not really additive, so if you enable that feature in the crate, essentially your crate
will work only on the exam, this is not really great for us, and we are trying to figure out how to
fix this. And also about Kimo, Kimo now started to support Rust. I mean, you can write
some devices, for example, in Rust into Kimo, and there is a thread about start to use our
crates to in Kimo itself for the Rust part. And other couple of ideas, many from Patrick, to
to sling down our volatized device to work better with virtual devices and to replace
byte value with zero copy. Okay, another, I mean, an issue that we had in these years
was related about our deep chain of dependency. So for example, Firecracker or VHOS device or
VHOS device, or VHOS device or to implement VHOS user, and the VHOS crate itself depends on the
VMBertio crate for the VHOS, that depends on VM memory to access the guest memory, that depends on
VMMMC's YouTube. So we have a really deep chain of dependency, and every time we change something,
for example, in VM memory, we need to be sure that we propagate the changes, and sometimes
contributor for God about it, maintain results for God about it. So we try to find parts of
solution, like try to automate the crates.io releases, but because we need to follow a strict
sequence of releases. So we need to release VMMC's YouTube first, then VMMertio, VMMemory, and so on.
So we try to automate crates.io. We try to use the dependency upgrade in a minor release,
but this is tricky, and what we are thinking about is to use a mono repo for all of our crates.
This should also answer the question on how to keep our configuration consistent. We try using
some model for our CI, for example, and but yeah, we are thinking about the mono repo.
We already did something for other crates. So essentially, when Rust VMMem started,
we had one repo, one repo per crate, and that was not really amazing. So during the years,
we tried to put crates together on the rough workspace, and for us every Rust workspace is a
Git repo. So for example, we merge KVM bindings and KVM, IOCTL, under a single workspace.
We did the same for VFIO, for VMVertio, and not for Vhost. And our next steps would be to put
everything together. This should at least, when someone touch something in a crate,
take care of the others. And so the idea is to put all the crates in Rust VMMem workspace,
which will be a single Git repo, and we will use path dependency. Of course, this will bring
up other issue. Like maybe we will need a stable branch and to avoid break stuff when we,
I mean, to have fixes to go more faster and stuff like that. But we hope that we solve the other issue
we find. So Ruhin started to work on that. We created the repo. We started to put the CIDER.
We started to move the VMMemC's utils there. Still working progress. I mean, we need to merge
the VMMemC's utils PR. But essentially, we hope to do that in the last few months.
And last thing is about risk five. Also, this is the work done by Ruhin in the last two years.
We started to support it. Mainly, we started for the CID. Now, we don't have hardware in our CID
that run the TAR risk five. So for now, we are using H86 machine with VMMem to fully emulate
the risk of risk five virtual machine. And inside that, we will run our container and our CID
that will run in every crate that used the Rust VMMemCI sub module. And about the crates,
the code that we saw that support risk five. You can see the one in the light orange
are the one that done. I mean, we don't have support for risk five right now in that crate.
But all the others should support it. So, future works. We hope to have some risk five
order to put into our CID system this year, not sure. And about crates, we are working.
I mean, many of our HIN is working to move also the rest of the crates. Like VHOS,
VHOS, VHOS, VHOS, VHOS, VHOS, as well. And that is it. If you want to join our community,
we will be really happy. This is the link that contains all the information. So, happy
question.
OK.
So thank you.
Really?
Want to join us?
There is a question?
Yeah.
Do you think it was so important that it would be visible
to run into the Waza?
WebAssembly, you mean?
Yeah.
The question was if we will run Rostia M.M.
Crates one day in WebAssembly.
Why not?
I don't know.
Maybe yes.
If you are interested, let's talk about it.
Or if you know someone interested would be cool.
For sure.
Thank you.
Yeah.
Welcome.
Any other question?
No.
OK.
Thank you.