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

[Steve Rutherford]

Hint received :)
Getting userspace instruction emulation to work with nested has been a
bit of a fight, and we've been waiting to push stuff upstream until we
have it everywhere.

On Wed, Dec 19, 2018 at 1:13 PM Paolo Bonzini <pbonzini at redhat.com> wrote:
>
> 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