Summary

Virtio is an abstraction for virtualized devices that enables additional features for guest operating systems, like faster networking and block I/O as well as virtfs for sharing a file system with the host.

Release Note

This feature is targetted for upstream kernel and qemu integration to help developers building their own packages. It can be integrated in a Linaro release if there is a need.

Rationale

Since physical machines have limitations in their availability to developers and users, as well as their capabilities, we want to be able to simulate an ARM system environment on a PC type system using qemu and have that provide a good user experience. The virtio-net and virtio-block device drivers can help to provide a faster simulation, while virtio-rng and virtio-9p provide extra features.

User stories

* Jacob is a developer and wants to build OpenOffice.org for ARM. He does not have access to a fast ARM machine so he uses qemu. Using virtio drivers means he saves two days of build time.

* Isabella is trying to build an image file for running Ubuntu on her iPad. She has used debootstrap to create a directory structure and is experimenting with it. She decides that she does not want to build the image file straight away, so she uses qemu with virtfs to boot directly into her subdirectory while she can still access it from the host.

Assumptions

* There are a lot of ARM platforms supported by qemu. For simply running a platform independent image, we use the "Versatile/PB" platform, which has the best qemu and kernel support, so this is the one that gets modified to support virtio. Other platforms could be done as well but are currently outside of the scope.

Design

VirtIO can use platform specific backends. The existing backends in the kernel are for PCI, s390 and lguest. Virtio on ARM will be based on the virtio-pci backend, which almost works and only needs bug fixes because of broken I/O space mappings in qemu.

Implementation

Both the kernel and qemu have problems with PCI I/O space accesses in the versatile platform. In the kernel, the pci_iomap function does not what it is supposed to do, so any PIO access causes an invalid pointer dereference. In qemu, the versatile platform does not have working support for I/O space access because the I/O mapping only gets registered for the realview platform, not versatile.

Further, the I/O space mapping in versatile is highly unusual, because I/O port numbers are defined to be identical to their MMIO address location, unlike other architectures that use a low range of I/O ports, typically 65536 ports starting at zero. This currently confuses the architecture independent PCI and PIO code in qemu, which needs to be extended to work on other ranges.

Unresolved issues

Patches need to be integrated upstream.

BoF agenda and discussion


CategorySpec

WorkingGroups/KernelArchived/Specs/VirtIO (last modified 2013-01-14 19:45:22)