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

[Christoph Hellwig]

On Thu, Apr 03, 2025 at 09:06:37AM +0100, David Woodhouse wrote:
> You are right, in theory, that (2b) is the job of ACPI or DT to
> communicate. But virtio is presented as just another PCI device,
> indistinguishable by the guest from other PCI devices which *are*
> actually able to do DMA through the hardware's two-stage IOMMU.

Then the virtual device should be behind a different IOMMU (or no IOMMU
at all) to clearly differciate them for the assigned hardware devices.

> To my knowledge there isn't a clean way, across platforms, to tell an
> operating system that a certain device just *can't* do DMA at all. 

Well, it's part of the device specific if it can do DMA or not.  We
had a bunch of early PCI (and a lot of ISA) device that could not
do P2P.  Even on PCIe there might be weirdo device that just expose
a bar or have some bitbanged i2c or similar.

Now if you mean virtio devices - yes there's no way currently as virtio
is a quite fundamentally DMA based model.

> And
> even if there was, why offer a device model that could *theoretically*
> do DMA, just to tell the guest through some other channel that it
> can't?

That would be the normal way.  Because virtio devices fundamentally can
do DMA.  It's just your guest specification doesn't want them to.

> What's wrong with a simple option to indicate, in the device model that
> the system designer chooses to build for the guest, that it can't do
> DMA?

As stated above I suspect you still are asking the wrong question and
have the wrong mental model.  Virtio fundamentally can do DMA, you just
don't want it to.  And based on the other subthread I also suspect you'd
actually be much better off with your bounce buffer in the virtual host
memory instead of coming up with this particularly odd case, but even
if not it's the system description that matters here, not the device
model.