[Rust-VMM] [Rust-vmm] Goals for this list

[Anthony Liguori]

Dylan Reid <dgreid at chromium.org> writes:

> On Mon, Dec 17, 2018 at 3:31 PM Liguori, Anthony <aliguori at amazon.com> wrote:
>>
>> 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.

>
> My concerns are only around build time. That's certainly something
> that can be optimized later and isn't specific to this use of bindgen.
>
> It would be great to improve the current, manual bindgen process. It
> will make using new KVM features easier.

Now that I've thought a bit about it, I think I prefer to commit bindgen
results because then the version of the crate becomes meaningful.  New
KVM features are tied to specific crate versions and you can set
dependencies accordingly.

The build.rs can definitely be improved though to make it easy to update
the committed results.

>> 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.
>
> sys_util can be broken in to smaller, easier to consume parts.
>
> The data_model crate has proven very useful, there is also a similar
> craten in the Fuchsia tree:
> https://fuchsia.googlesource.com/garnet/+/master/public/rust/zerocopy/src/lib.rs
> It might be worth considering too.

Oh, neat.  I will take a look.

Regards,

Anthony Liguori