On Apr 14, 2022, at 9:10 AM, Wei Liu wl@xen.org wrote:
On Thu, Apr 14, 2022 at 02:36:12PM +0100, Alex Bennée wrote:
Wei Liu wl@xen.org 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.
I think this is a strong reason for not using existing C libraries. It would be nice if the APIs can work with no_std.
This was the goal I had with the way I structured the xen-sys crate.
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.
Same area I had an interest in. As well. I played with a xenstore implementation in a unikernel as well. Some of the code was published but unfortunately the actual functional bits were not.
— Doug