** This page is currently work-in-progress and not to be shared **

Introduction to VirtIO

VirtIO is a virtual device driver standard developed originally for the Linux kernel, drawing upon the lessons learned during the development of paravirtualized device drivers for Xen, KVM and other hypervisors. It aimed to become a “de-facto standard for virtual I/O devices”, and to some extent has succeeded in doing so. VirtIO is now This document describes technical context and analysis to support a proposal for development of a new Linux device driver destined for mainline Linux and use by OpenXT, to introduce Hypervisor-Mediated data eXchange (HMX) into the data transport of the popular VirtIO suite of Linux virtual device drivers, by leveraging Argo in Xen. Daniel Smith proposed this idea, which has been supported in discussions by Christopher Clark and Rich Persaud of MBO/BAE Systems, and Eric Chanudent and Nick Krasnoff of AIS. Christopher is the primary author of this version of this document.

– August 2020

Introduction to VirtIO

VirtIO is a virtual device driver standard developed originally for the Linux kernel, drawing upon the lessons learned during the development of paravirtualized device drivers for Xen, KVM and other hypervisors. It aimed to become a “de-facto standard for virtual I/O devices”, and to some extent has succeeded in doing so. VirtIO is now widely implemented in both software and hardware, it is commonly the first choice for virtual driver implementation in new virtualization technologies, and the specification is now maintained under governance of the OASIS open standards organization.

...

Adding Argo as a transport for VirtIO will retain Argo’s MAC policy checks on all data movement, while allowing use of the VirtIO virtual device drivers and device implementations.

...

OpenXT can retire use of the Xen PV drivers in some workloads, to be replaced by device implementations.

...

With the VirtIO virtual device drivers with using the VirtIO-Argo transport driver, OpenXT can retire use of the Xen PV drivers within platform VMs and guest workloads. This removes shared memory from the data path of the device drivers, allows for some hypervisor functionality, such as the grant tables, to be disabled, and makes the virtual device driver data path HMX-compliant.

TODO:

The VirtIO with Argo transport driver and select VirtIO front-end drivers will be included in the Linux platform VMs of OpenXT, replacing the existing use of Xen PV drivers.

• Swap out Xen PV block and PV net for virtio-argo

  • todo: NDVMs….

• < turn off the grant tables >

• < toolstack stuff: frontend, backend, xenstore … >

• XSM/Flask policy

• XSM firewall implementation

...

In addition, as new virtual device classes in Linux have VirtIO drivers implemented, these should transparently be enabled with Mandatory Access Control, via the existing virtio-argo transport driver, potentially without further effort required – although please note that for some cases (eg. graphics) optimizing performance characteristics may require additional effort.

VirtIO with Argo: architecture and design

TODO:

• Design of the ACPI-table-based virtual device discovery mechanism for the VirtIO-Argo transport

• Research and design of the Argo-virtio backend transport architecture

  • Toolstack

  • QEMU

  • Review XSM/Flask policy control points in Argo for the split-driver use case

  • xenstore interaction, if any

Needed

• An Argo specification document

  • Required for supporting embedded system evaluationsAppropriate

    • Repeatedly requested by interested parties in the Xen ecosystem who work with safety requirements.

  • This will be appropriate for inclusion in the Xen documentionProject documentation

• A performance evaluation of Argo

  • Report required to support external evaluations of Argo

    • Question has been raised in every forum where Argo has been presented

  • Needs to cover Intel, AMD and Arm platforms

    • Variation in processor cache architectures and memory consistency models likely to have appreciable effects

  • Development to improve performance based on measurements

    • Notification delivery is a known area where improvement may should be possible

      • See the first series of Argo posted during Xen upstreaming for a non-event based interrupt delivery path

  • Split-driver use case is a priority

    • bandwidth important for bulk data transport

    • latency important for interactive and media-delivery (eg. IVI systems)

...