[Kata-hypervisor] Firecracker Micro-VM

Paolo Bonzini pbonzini at redhat.com
Tue Nov 27 10:09:12 UTC 2018

On 27/11/18 10:33, Jon Olson wrote:
> On Tue, Nov 27, 2018, 1:13 AM Paolo Bonzini <pbonzini at redhat.com
> <mailto:pbonzini at redhat.com> wrote:
>     On 27/11/18 06:42, Liguori, Anthony via Kata-hypervisor wrote:
>     > On a personal note, I absolutely love Rust!  I think the language
>     was made for this purpose.
>     Yes, it's very interesting.  I hope to introduce Rust in QEMU too, and
>     I'd love to discuss with you (also based on your QEMU background) what
>     you think is the best way to hook Rust and C together.
> Go the other direction -- use the C as spec, and build up the Rust to
> meet it.
> Don't marry C and Rust unless you have a use case that requires it.

My use case is that, for example, having virtqueue processing in Rust
would give me 90% of the benefit of a full rewrite already.  It's
possibly the only part of QEMU that runs all the time, is exposed to
untrusted data and needs to be damn fast.

For the specific case of virtqueues, pushing them out of process by
writing a vhost-user server in Rust would make sense too.  However, you
still would not be able to reduce the attack surface of the control plane.

QEMU being written in C rather than C++ makes it much simpler to use
Rust's FFI; the complicated part of C+Rust seems to be mapping lifetimes
back to e.g. C reference counts.  That probably means one of these:

1) writing something like Rc or Arc, that sends ref and unref operations
back to C.  In theory the advantage is that you write the least Rust
code, in practice your reimplementation would be much less polished than
the Rust standard library so I don't think it's a good idea.

2) converting the core data structures to Rust and then writing a C
wrapper for them.  The disadvantage is that you have to work bottom-up.
 On the other hand, the core data structures are also where we have the
best testcases so it's probably the easiest.

3) for very special cases such as functions that absolutely have to be
inlined, writing the same code twice, in both Rust and C.  This would be
the case for something like RCU's read side.


>     A while ago I looked at https://github.com/crossbeam-rs/crossbeam-epoch,
>     and it seemed like it could be adapted to become an RCU implementation
>     and/or a wrapper for QEMU's RCU.  This would be very important since RCU
>     is used for several central data structures in QEMU (e.g. the memory
>     regions).
>     Paolo
>     _______________________________________________
>     Kata-hypervisor mailing list
>     Kata-hypervisor at lists.katacontainers.io
>     <mailto:Kata-hypervisor at lists.katacontainers.io>
>     http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-hypervisor

More information about the Kata-hypervisor mailing list