With confidential computing, the hypervisor/VMM component which implements
a virtio device model may not have access to arbitrary guest system memory.

There are various ways to deal with this restriction. Enlightenments in
the core guest operating system can ensure that DMA buffers are shared,
or unencrypted, depending on the type of protection. But that does need
the OS core to support such new mechanisms.

Some IOMMU hardware now supports two-stage operation, where true device
DMA is translated first through guest IOVA→GPA page tables, and then
through GPA→HPA page tables provided by the hypervisor. Such a setup
works well enough for physical devices, but hardware designers working
on such IOMMUs usually 'forget' to expose details like IOTLB flushes to
the hypervisor, making it impractical even for 'trusted' software like
pKVM to snoop on the stage 1 page tables and permit VMM access where
such access would be permitted to a real device.

Implementing a virtio-iommu is another possibility, although such would
often have to be implemented in the trusted part of the hypervisor (e.g.
pKVM) *and* it would often have to live alongside the true 2-stage IOMMU
passed through for physical devices, with corresponding indications to
the guest about which device lives behind which IOMMU.

The simplest option by far is just to allow for a virtio device which
conceptually doesn't do DMA at all. It just has an "on-device" memory
region and does all its data transfer to/from that region.

In fact, this should basically already work for virtio-mmio devices in
the device-tree, as DT bindings for a `restricted-dma-pool` were defined
in 2021 which apply to *all* devices:
https://lore.kernel.org/all/20210624155526.2775863-1-tientzu@chromium.org/

The `restricted-dma-pool` DT binding doesn't specifically address virtio,
and didn't make any attempt at handling backward compatibility. If an
operating system recognises the `restricted-dma-pool` and does the right
thing, yay! Else, it would just continue to use system DMA addresses as
before, which may or may not work.

This series adds a VIRTIO_F_SWIOTLB feature to negotiate the use of a 
buffer region which is provided by the transport, and documents the
`restricted-dma-pool` option on the virtio-mmio transport. Then adds
a similar capability via VIRTIO_PCI_CAP_SWIOTLB for the PCI transport.

David Woodhouse (3):
      content: Add VIRTIO_F_SWIOTLB to negotiate use of SWIOTLB bounce buffers
      transport-mmio: Document restricted-dma-pool SWIOTLB bounce buffer
      transport-pci: Add SWIOTLB bounce buffer capability

 content.tex        | 12 ++++++++++++
 transport-mmio.tex | 33 +++++++++++++++++++++++++++++++++
 transport-pci.tex  | 33 +++++++++++++++++++++++++++++++++
 3 files changed, 78 insertions(+)