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. Thanks, Wei.
