Re: Virtio on Xen with Rust

[Doug Goldstein <cardoe@xxxxxxxxxx>]

> On Apr 14, 2022, at 9:10 AM, Wei Liu <wl@xxxxxxx> wrote:
> 
> On Thu, Apr 14, 2022 at 02:36:12PM +0100, Alex Bennée wrote:
>> 
>> 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.
>> 
> 
> 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