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

[Paolo Bonzini]

On 18/12/18 00:30, Liguori, Anthony wrote:
> As a side note, I think having OS X hypervisor framework bindings
> and whatever the new Windows thing is would be pretty cool.

Yes, indeed.  Hypervisor.framework however is much more complex than KVM
or WHP because you deal manually with VMCSes and have to do instruction
emulation in userspace.  QEMU takes a stab at it, but it's not as stable
as KVM.

*However* Google does have patches for KVM to do instruction emulation
in userspace, and I'd like to apply them upstream too now that KVM has
an API test framework (and thus we can know they won't bitrot).
(Steve, you are in Cc because hint, hint :)).  Once that is in place, I
guess a minimal x86 emulator written in Rust, porting the emulator code
that QEMU has for Hypervisor.framework, would be a fun GSoC project for
a very good student.

> 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.

virtio would be interesting.  One initial target could be a demo
vhost-user client, it has to set up a memory map, parse vrings, handle
endianness, etc.  It would be an interesting benchmark for a DMA API.

The control plane (your item 3) by comparison is a bit less interesting.

Paolo