[Rust-VMM] Remaining Xen enabling work for rust-vmm

[Alex Bennée]

Hi,

This is one of several emails to follow up on Linaro's internal KWG
sprint last week in Cambridge where a number of Project Stratos hackers
discussed what next steps we have and started to think about future
work. I am splitting the update into several emails so I can freely CC
the relevant lists for each without too much cross-posting spam.

Intro
=====

We've made good progress over the last year and have up-streamed a number
of device models as vhost-user daemons. We have also gotten our first
proof of concept build of the xen-vhost-master which has allowed us to
reuse these backends on the Xen hypervisor.

  https://github.com/vireshk/xen-vhost-master

Remaining Work
==============

Scope out the remainder of APIs needed for oxerun
-------------------------------------------------

The current xen-vhost-master uses a combination of the native rust
oxerun and a bindgen import of libxensys
(https://github.com/vireshk/libxen-sys) and a number of xen libraries
built directly in the xen-vhost-master repository.

Our intention for the Stratos work is to remove any C dependency for the
rust backend and use native rust bindings to talk to the hypervisor
control ioctl.

Identifying what is needed should be easy enough as we can see where in
master repository C calls are being made. This work should be broken
down into groups in JIRA so the work can be efficiently divided up.

Currently our focus for the rust-vmm repo is to support the vhost-user
daemons but a wider conversation needs to be had with the community
about the rest of the tooling involved in the creation and control of
DomU guests. For Stratos we would like to explore the possibilities of
bare metal monitor programs for dom0-less (or dom0-light?) setups.

Strategy for testing oxerun in the rust-vmm project
---------------------------------------------------

Currently the rust-vmm projects rely heavily on unit tests and a (mostly) x86
build farm. While building for non-x86 architectures isn't
insurmountable doing blackbox testing on real hypervisors isn't
currently supported. Given the low level nature of the interactions
simply mocking the ioctl interface to the kernel will not likely
sufficiently exercise things.

We need a way to execute tests on a real system with a real Xen
hypervisor and dom0 setup. We can either:

  - somehow add Xen hosts to the Buildkite runner pool for rust-vmm
  or
  - investigate using QEMU TCG as a portable system in a box to run Xen
  and guests

Currently this is blocking wider up-streaming of the oxerun code to
https://github.com/rust-vmm/xen-sys in the same way other rust-vmm repos
work.

See also
========

Other subjects discussed will be the subject of other emails today with
different distribution lists. These are:

  - Remaining work for vhost-device
  - Additional virtio devices
  - Integrating rust-vmm with QEMU

Happy reading ;-)

-- 
Alex Bennée