Re: Virtio on Xen with Rust

[Wei Liu <wl@xxxxxxx>]

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.

Wei.

> 
> ~Andrew