Is it time to start implementing Xen bindings for rust-vmm?

* Is it time to start implementing Xen bindings for rust-vmm?
@ 2021-09-13 12:44 Alex Bennée
  2021-09-13 15:32 ` Andrew Cooper
  2021-09-22 12:03 ` David Woodhouse
  0 siblings, 2 replies; 7+ messages in thread
From: Alex Bennée @ 2021-09-13 12:44 UTC (permalink / raw)
  To: Mathieu Poirier, Viresh Kumar, Wei Liu
  Cc: rust-vmm, xen-devel, Stratos Mailing List, Oleksandr Tyshchenko,
	Stefano Stabellini

Hi,

As we consider the next cycle for Project Stratos I would like to make
some more progress on hypervisor agnosticism for our virtio backends.
While we have implemented a number of virtio vhost-user backends using C
we've rapidly switched to using rust-vmm based ones for virtio-i2c,
virtio-rng and virtio-gpio. Given the interest in Rust for implementing
backends does it make sense to do some enabling work in rust-vmm to
support Xen?

There are two chunks of work I can think of:

  1. Enough of libxl/hypervisor interface to implement an IOREQ end point.

  This would require supporting enough of the hypervisor interface to
  support the implementation of an IOREQ server. We would also need to
  think about how we would map the IOREQ view of the world into the
  existing vhost-user interface so we can re-use the current vhost-user
  backends code base. The two approaches I can think of are:

    a) implement a vhost-user master that speaks IOREQ to the hypervisor
    and vhost-user to the vhost-user slave. In this case the bridge
    would be standing in for something like QEMU.

    b) implement some variants of the vhost-user slave traits that can
    talk directly to the hypervisor to get/send the equivalent
    kick/notify events. I don't know if this might be too complex as the
    impedance matching between the two interfaces might be too great.

  This assumes most of the setup is done by the existing toolstack, so
  the existing libxl tools are used to create, connect and configure the
  domains before the backend is launched.

which leads to:

  2. The rest of the libxl/hypervisor interface.

  This would be the rest of the interface to allow rust-vmm tools to be
  written that could create, configure and manage Xen domains with pure
  rust tools. My main concern about this is how rust-vmm's current model
  (which is very much KVM influenced) will be able to handle the
  differences for a type-1 hypervisor. Wei's pointed me to the Linux
  support that was added to expose a Hyper-V control interface via the
  Linux kernel. While I can see support has been merged on other rust
  based projects I think the rust-vmm crate is still outstanding:

    https://github.com/rust-vmm/community/issues/50

  and I guess this would need revisiting for Xen to see if the proposed
  abstraction would scale across other hypervisors.

Finally there is the question of how/if any of this would relate to the
concept of bare-metal rust backends? We've talked about bare metal
backends before but I wonder if the programming model for them is going
to be outside the scope of rust-vmm? Would be program just be hardwired
to IRQs and be presented a doorbell port to kick or would we want to
have at least some of the higher level rust-vmm abstractions for dealing
with navigating the virtqueues and responding and filling in data?

Thoughts?

-- 
Alex Bennée

^ permalink raw reply	[flat|nested] 7+ messages in thread