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.

~Andrew

Reply via email to