[Rust-VMM] Is it time to start implementing Xen bindings for rust-vmm?
alex.bennee at linaro.org
Tue Sep 14 14:44:01 UTC 2021
Andrew Cooper <andrew.cooper3 at citrix.com> writes:
> On 13/09/2021 13:44, Alex Bennée wrote:
>> 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.
> 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.
Are these in the rust-vmm project is elsewhere?
> 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
Just to clarify nomenclature is a PVH stubdomain what I'm referring to
as a bare metal backend, i.e: a unikernel or RTOS image that implements
the backend without having to transition between some sort of userspace
and it's supporting kernel?
> 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.
Are the hypercalls mediated by a kernel layer or are you making direct
HVC calls (on ARM) to the hypervisor from userspace?
Where would I look in the Xen code to find the hypercalls that are
considered stable and won't change between versions?
> It's high time the Xen Rust working group (which has been talked about
> for several years now) actually forms...
Indeed part of the purpose of this email was to smoke out those who are
interested in the intersection of Xen, Rust and VirtIO ;-)
More information about the Rust-vmm