Re: Virtio on Xen with Rust

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

Wei Liu <wl@xxxxxxx> writes:

> On Thu, Apr 14, 2022 at 12:07:10PM +0000, Andrew Cooper wrote:
>> On 14/04/2022 12:45, Wei Liu wrote:
>> > Hi Viresh
>> >
>> > This is very cool.
>> >
>> > On Thu, Apr 14, 2022 at 02:53:58PM +0530, Viresh Kumar wrote:
>> >> +xen-devel
>> >>
>> >> On 14-04-22, 14:45, Viresh Kumar wrote:
>> >>> Hello,
>> >>>
>> >>> We verified our hypervisor-agnostic Rust based vhost-user backends with 
>> >>> Qemu
>> >>> based setup earlier, and there was growing concern if they were truly
>> >>> hypervisor-agnostic.
>> >>>
>> >>> In order to prove that, we decided to give it a try with Xen, a type-1
>> >>> bare-metal hypervisor.
>> >>>
>> >>> We are happy to announce that we were able to make progress on that 
>> >>> front and
>> >>> have a working setup where we can test our existing Rust based backends, 
>> >>> like
>> >>> I2C, GPIO, RNG (though only I2C is tested as of now) over Xen.
>> >>>
>> >>> Key components:
>> >>> --------------
>> >>>
>> >>> - Xen: https://github.com/vireshk/xen
>> >>>
>> >>>   Xen requires MMIO and device specific support in order to populate the
>> >>>   required devices at the guest. This tree contains four patches on the 
>> >>> top of
>> >>>   mainline Xen, two from Oleksandr (mmio/disk) and two from me (I2C).
>> >>>
>> >>> - libxen-sys: https://github.com/vireshk/libxen-sys
>> >>>
>> >>>   We currently depend on the userspace tools/libraries provided by Xen, 
>> >>> like
>> >>>   xendevicemodel, xenevtchn, xenforeignmemory, etc. This crates provides 
>> >>> Rust
>> >>>   wrappers over those calls, generated automatically with help of bindgen
>> >>>   utility in Rust, that allow us to use the installed Xen libraries. 
>> >>> Though we
>> >>>   plan to replace this with Rust based "oxerun" (find below) in longer 
>> >>> run.
>> >>>
>> >>> - oxerun (WIP): 
>> >>> https://gitlab.com/mathieupoirier/oxerun/-/tree/xen-ioctls
>> >>>
>> >>>   This is Rust based implementations for Ioctl and hypercalls to Xen. 
>> >>> This is WIP
>> >>>   and should eventually replace "libxen-sys" crate entirely (which are C 
>> >>> based
>> >>>   implementation of the same).
>> >>>
>> > I'm curious to learn why there is a need to replace libxen-sys with the
>> > pure Rust implementation. Those libraries (xendevicemodel, xenevtchn,
>> > xenforeignmemory) are very stable and battle tested. Their interfaces
>> > are stable.
>> 
>> Very easy.  The library APIs are mess even if they are technically
>> stable, and violate various commonly-agreed rules of being a libary such
>> as not messing with stdout/stderr behind the applications back, and
>> everything gets more simple when you remove an unnecessary level of C
>> indirection.
>
> You don't have to use the stdio logger FWIW. I don't disagree things can
> be simpler though.

Not directly related to this use case but the Rust API can also be
built to make direct HYP calls which will be useful for building Rust
based unikernels that need to interact with Xen. For example for a
dom0less system running a very minimal heartbeat/healthcheck monitor
written in pure rust.

We would also like to explore unikernel virtio backends but I suspect
currently the rest of the rust-vmm virtio bits assume a degree of POSIX
like userspace to set things up.

-- 
Alex Bennée