[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Virtio in Xen on Arm (based on IOREQ concept)

Hello all.

We would like to resume Virtio in Xen on Arm activities. You can find some
background at [1] and Virtio specification at [2].

*A few words about importance:*
There is an increasing interest, I would even say, the requirement to have
flexible, generic and standardized cross-hypervisor solution for I/O virtualization
in the automotive and embedded areas. The target is quite clear here.
Providing a standardized interface and device models for device para-virtualization
in hypervisor environments, Virtio interface allows us to move Guest domains
among different hypervisor systems without further modification at the Guest side.
What is more that Virtio support is available in Linux, Android and many other
operating systems and there are a lot of existing Virtio drivers (frontends)
which could be just reused without reinventing the wheel. Many organisations push
Virtio direction as a common interface. To summarize, Virtio support would be
the great feature in Xen on Arm in addition to traditional Xen PV drivers for
the user to be able to choose which one to use.

*A few word about solution:*
As it was mentioned at [1], in order to implement virtio-mmio Xen on Arm requires
some implementation to forward guest MMIO access to a device model. And as it
turned out the Xen on x86 contains most of the pieces to be able to use that
transport (via existing IOREQ concept). Julien has already done a big amount
of work in his PoC (xen/arm: Add support for Guest IO forwarding to a device emulator).
Using that code as a base we managed to create a completely functional PoC with DomU
running on virtio block device instead of a traditional Xen PV driver without
modifications to DomU Linux. Our work is mostly about rebasing Julien's code on the actual
codebase (Xen 4.14-rc4), various tweeks to be able to run emulator (virtio-disk backend)
in other than Dom0 domain (in our system we have thin Dom0 and keep all backends
in driver domain), misc fixes for our use-cases and tool support for the configuration.
Unfortunately, Julien doesn’t have much time to allocate on the work anymore,
so we would like to step in and continue.

*A few word about the Xen code:*
You can find the whole Xen series at [5]. The patches are in RFC state because
some actions in the series should be reconsidered and implemented properly.
Before submitting the final code for the review the first IOREQ patch (which is quite
big) will be split into x86, Arm and common parts. Please note, x86 part wasn’t
even build-tested so far and could be broken with that series. Also the series probably
wants splitting into adding IOREQ on Arm (should be focused first) and tools support
for the virtio-disk (which is going to be the first Virtio driver) configuration before going
into the mailing list.

What I would like to add here, the IOREQ feature on Arm could be used not only
for implementing Virtio, but for other use-cases which require some emulator entity
outside Xen such as custom PCI emulator (non-ECAM compatible) for example.

*A few word about the backend(s):*
One of the main problems with Virtio in Xen on Arm is the absence of
“ready-to-use” and “out-of-Qemu” Virtio backends (I least am not aware of).
We managed to create virtio-disk backend based on demu [3] and kvmtool [4] using
that series. It is worth mentioning that although Xenbus/Xenstore is not supposed
to be used with native Virtio, that interface was chosen to just pass configuration from toolstack
to the backend and notify it about creating/destroying Guest domain (I think it is
not bad since backends are usually tied to the hypervisor and can use services
provided by hypervisor), the most important thing here is that all Virtio subsystem
in the Guest was left unmodified. Backend wants some cleanup and, probably,
refactoring. We have a plan to publish it in a while.

 

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.

Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.