Re: [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use of SWIOTLB bounce buffers

[Christoph Hellwig]

On Fri, Apr 04, 2025 at 08:50:47AM +0100, David Woodhouse wrote:
> I do agree, this is fundamentally a system issue. In a CoCo model, it's
> non-trivial for the system to allow *virtual* devices to do "DMA"
> because that actually means allowing the VMM to access arbitrary guest
> memory.


> So "for the emulated devices, just use a device model that doesn't do
> arbitrary DMA to system memory" is a nice simple answer, and keeps the
> guest support restricted to its *own* standalone driver.

It's also one that completely breaks the abstraction.  I still don't
understand what the problem is with having the paravirtualized devices
on a different part of the virtual PCIe topology so that the stage2
IOMMU isn't used for them, but instead just the direct mapping or a
stub viommu that blocks all access.

> What's annoying is that this should work out of the box *already* with
> virtio-mmio and a `restricted-dma-pool` — for systems which aren't
> afflicted by UEFI/ACPI/PCI as their discovery mechanisms.

Yes.  And the fix is to get the equivalent to restricted-dma-pool into
UEFI/ACPI.  That gives you a portable and device-independent way to
describe this limitation, which is much better than hacking around it
using an odd device model.