[Rust-VMM] Goals for this list

[Anthony Liguori]

"Florescu, Andreea" <fandree at amazon.com> writes:

> Hi,
>
> I also started a "research" so to say about what crates we can share.
> I am working on a proposal and should have something ready in a few
> days.
>
> For the device models, I think a better approach would be to also
> include virtio devices, but export each of them individually using
> rust features (like we are currently doing in Firecracker with the
> vsock device).
>
> One question I have is where would we host the crates? An organization
> on GitHub with all these crates would be super cool. Something like
> "rust-vmm" maybe?

I think we should get some code for the easy stuff (like KVM crate),
demonstrate it working with Firecracker and Crosvm, and then we can
figure this out.

Probably a new GitHub org though.

Regards,

Anthony Liguori

>
> Andreea
>
> ----------------------------------------------------------------------
> From: Liguori, Anthony <aliguori at amazon.com>
> Sent: Tuesday, December 18, 2018 1:30 AM
> To: rust-vmm at lists.opendev.org
> Subject: [UNVERIFIED SENDER] [Rust-vmm] Goals for this list 
>
> Hi!
>
> Very excited about this list and eager to begin discussions. I wanted
> to start with what I see as the low hanging fruit and I what I see as
> the goal of this effort.
>
> I'd like to build a set of crates, preferrably with a common name,
> that make it really easy to write VMMs in Rust. I think Rust is an
> ideal language for building VMMs and that if the right primitives are
> there, a lot of interesting VMMs will emerge.
>
> Some ideas I have for what would make good core creates:
>
> 1) KVM bindgen bindings. Right now, there is an issue with bindgen
> misgenerating code when encountering empty trailing arrays which are
> used in KVM. Both crosvm and Firecracker get around this by modifying
> the headers by hand and then committing the results of bindgen. Dylan
> also mentioned that they were unhappy about bindgen performance but
> this seems like an eventual optimization to me.
>
> As a side note, I think having OS X hypervisor framework bindings and
> whatever the new Windows thing is would be pretty cool. Maybe there's
> room for a wrapper around the three but it's not something that
> interesting to me in the near term.
>
> 2) The crosvm data_model crate. This one is super critical but easy to
> misunderstand as it allows for safe access to volatile memory.
> Somewhat related is the mmap() bits from sys_util. Not sure how the
> crosvm folks feel but I think there is some refactoring here that
> could be useful to build a memory crate.
>
> 3) Some traits for device model implementations. It's easy to really
> bike shed here so I reckon it's best to start with a concrete device
> model like a UART, work through what is required for interfaces, and
> then iterate from there.
>
> 4) Common device models with only a single implementation (i.e.
> 16650A). Not sure about virtio, maybe.
>
> Curious what other people think here too. I've got a couple weeks off
> coming up so I'd love to have some projects to have on here.
>
> Regards,
>
> Anthony Liguori