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

[Alex Bennée <alex.bennee@xxxxxxxxxx>]

Andrew Cooper <andrew.cooper3@xxxxxxxxxx> writes:

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

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

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 ;-)

-- 
Alex Bennée