Versions Compared

Version Old Version 72 New Version 73
Changes made by

Christopher Clark

Christopher Clark

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Interface Name

Upstream Considerations

Pro properties

Con properties

Frontend consumers

Backend consumers

VirtIO-Argo transport driver

  • Destination: mainline Linux kernel, via the Xen community

  • Argo will need to become security-supported in Xen

  • Enables use of existing mainline Linux VirtIO virtual device drivers, expanding the available virtual device types without requiring development or maintenance

  • Mandatory Access Control enforcement

VirtIO interfaces are developed by a standards committee (OASIS), so can move slower

Mainline Linux VirtIO device drivers

None

Existing OpenXT Linux Argo device driver

  • Not acceptable

  • Tested and functional over an extended period

Implementation is unsuitable for further development

  • Existing libargo

  • Interposer library

  • Interdomain DBUS

  • Argo firewall configuration tool

  • libxl state machine for VM lifecycle, indirectly

Bromium uXen v4v device drivers, straight port to Argo: VSock interface

  • Already present in uXen software distribution

  • For mainline Linux, or Xen: Unacceptable override of AF_VSOCK for a non-vsock interface, will require resolution

  • Strong code foundation for future development

  • Simpler interface and implementation than the current OpenXT driver

AF_VSOCK use needs resolving

  • Potentially OpenXT service VMs; though VirtIO-Argo may be better suited

  • Ported uXen v4v storage and network drivers

  • Ported libargo

OpenXT platform VMs

Bromium uXen v4v device drivers, port to Argo and expose char device

char device could be a challenge to justify

Functional even when kernel is configured without networking support

Non-standard char IOCTL interface rather than a networking standard

  • Ported uXen v4v storage and network drivers

  • Ported libargo

  • OpenXT platform VMs

  • Ported libargo

  • Ported interposer

  • Potentially a backend to VirtIO-Argo - to be determined

Bromium uXen v4v device drivers, port to Argo and expose network device

network device interface needs to be evaluated for upstream acceptability

Could avoid exposing Argo to userspace at all

  • Requires kernel configuration that includes networking

  • Limited interface if networking-only, as does not expose all wanted/needed functions

  • Ported uXen v4v storage and network drivers

  • Ported libargo

  • OpenXT platform VMs

  • Ported libargo

  • Ported interposer

  • Potentially a backend to VirtIO-Argo - to be determined

Bromium uXen v4v device drivers, port to Argo and expose both char and network devices, each optional via KCONFIG

Larger aggregate driver size for upstreaming work

  • Flexible

  • supports standard networking interface expectations

  • char interface can support Argo firewall and misc functions + comms when networking not present

  • Potentially OpenXT service VMs; though VirtIO-Argo may be better suited

  • Ported uXen v4v storage and network drivers

  • Ported libargo

  • OpenXT platform VMs

  • Ported libargo

  • Ported interposer

  • Potentially a backend to VirtIO-Argo - to be determined

Xen IOREQ for connection to VirtIO-Argo

Appropriate for Xen community, given current VirtIO IOREQ activity

  • Adheres to existing Xen architecture

  • Can simplify a userspace device model implementation

Requires use of emulation infrastructure in the hypervisor and a privileged domain, foreign memory mapping privilege, grants and event channels

None

Device emulators for providing virtual devices

...

Considerations on system architecture for the new driver structure

  • Changes to the software that will run in the guests:

    • This will affect evaluations of Xen systems that adopt VirtIO-Argo software:

      • Xen device drivers will may not be required within guests any more, since the VirtIO network and block alternatives can be operational instead.Similarly xenstore .

      • VirtIO device drivers may be required within guests and will most commonly be obtained from inclusion in the upstream Linux kernel.

      • Xenstore may no longer be required to support guests running with virtual devices enabled.

  • Changes to the software that will run in the platform VMs:

    • VirtIO virtual device emulation software will support guest virtual devices

    • XSM/Flask policy will have granular control over guest access to virtual devices

    • Will not require shared memory for device driver operations

  • Toolstack changes

    • VirtIO-Argo will not require xenstore, although QEMU may have dependency on it

    • XSM Argo firewall will not require libxl hooks to the VM lifecycle state machine to configure the Argo firewall, instead enforcement will be applied by a static system XSM policy

  • Hypervisor software changes

    • A different selection of hypervisor functionality will be enabled and disabled via KConfig options

      • some options will become mandatory: eg. Argo, XSM

      • some options may no longer be required: eg. Xenstore supportmandatory

  • Multi-hypervisor systems:

    • There have been design discussions about how to enable communication with Argo between VMs at different levels of nested hypervisors: this can then be applied to the VirtIO-Argo use case for Argo. It will enable driver domains to be hosted at different levels of nesting, and hosted on different hypervisors.

...