Re: Is it time to start implementing Xen bindings for rust-vmm?

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/09/2021 13:44, Alex Bennée wrote:
> Hi,
>
> As we consider the next cycle for Project Stratos I would like to make
> some more progress on hypervisor agnosticism for our virtio backends.
> While we have implemented a number of virtio vhost-user backends using C
> we've rapidly switched to using rust-vmm based ones for virtio-i2c,
> virtio-rng and virtio-gpio. Given the interest in Rust for implementing
> backends does it make sense to do some enabling work in rust-vmm to
> support Xen?
>
> There are two chunks of work I can think of:
>
>   1. Enough of libxl/hypervisor interface to implement an IOREQ end point.

No libxl here at all.

As of Xen 4.15, there are enough stable interfaces to implement simple
IOERQ servers.

https://github.com/xapi-project/varstored/commit/fde707c59f7a189e1d4e97c1a4ee1a2d0c378ad1
was the commit where I removed the final unstable interface from
varstored (terrible name) which is a dom0 backend for UEFI secure
variable handling.  As such, it also serves as a (not totally simple)
reference of an IOERQ server.


There are a few bits and pieces of rust going on within Xen, and a whole
load of plans.  Also, there is a lot of interest from other downstreams
in being able to write Rust backends.

We've got a placeholder xen and xen-sys crates, and placeholder work for
supporting cross-compile as x86 PV and PVH stubdomains.

The want to have a simple IOREQ server compiled either as a dom0
backend, or as a PV or PVH stubdomains influences some of the design
decisions early on, but they're all no-brainers for the longevity of the
work.

I started work on trying to reimplement varstored entirely in Rust as a
hackathon project, although ran out of time trying to make hypercall
buffers work (there is a bug with Box and non-global allocators causing
rustc to hit an assert().  In the short term, we'll have to implement
hypercall buffers in a slightly more irritating way).

Furthermore, stick to the stable hypercalls only.  Xen's C libraries are
disaster for cross-version compatibility, and you absolutely do not want
to recompile your rust program just to run it against a different
version of the hypervisor.  The plan is to start with simple IOREQ
servers, which are on fully stable interfaces, then stabilise further
hypercalls as necessary to expand functionality.

It's high time the Xen Rust working group (which has been talked about
for several years now) actually forms...

~Andrew