Message-ID: <2f1b06fea126352b153faf44911a7066c83faa82.camel@infradead.org>
Date: Thu, 03 Apr 2025 08:45:22 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: virtio-comment@...ts.linux.dev, hch@...radead.org, Claire Chang
 <tientzu@...omium.org>, linux-devicetree <devicetree@...r.kernel.org>, Rob
 Herring <robh+dt@...nel.org>, Jörg Roedel
 <joro@...tes.org>,  iommu@...ts.linux-foundation.org,
 linux-kernel@...r.kernel.org, graf@...zon.de
Subject: Re: [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use
 of SWIOTLB bounce buffers

On Thu, 2025-04-03 at 03:31 -0400, Michael S. Tsirkin wrote:
> On Wed, Apr 02, 2025 at 06:10:53PM +0100, David Woodhouse wrote:
> > On Wed, 2025-04-02 at 12:43 -0400, Michael S. Tsirkin wrote:
> > > 
> > > yes.
> > > 
> > > I know a bit more about PCI, and for PCI I prefer just not saying
> > > anything. The platform already defines whether it is behind an iommu
> > > or not, and duplication is not good.
> > 
> > Not a hill for me to die on I suppose, but I would personally prefer to
> > spell it out in words of one syllable or fewer, to make *sure* that
> > device and driver authors get it right even though it's "obvious".
> > 
> > After all, if we could trust them to do their thinking, we would never
> > have had the awful situation that led to VIRTIO_F_ACCESS_PLATFORM
> > existing in the first place; the legacy behaviour we get when that bit
> > *isn't* set would never have happened.
> 
> Oh, you are wrong here. It's not implementer's fault.
> virtio just was not designed with real DMA
> in mind, and micro-optimizing by bypassing the DMA API
> was very much intentional.

That's one point of view, I suppose. In the early days of IOMMUs, and
DMA ops coming to mainstream platforms, we found a *lot* of device
drivers that had the same "micro-optimisation" of just handing physical
addresses directly to devices. We called them 'bugs' though.

And the thing that was different for virtio-pci was that the host side
had the *same* bug, as I recall, so we had to introduce a feature bit
to declare/negotiate the "natural" behaviour.

But we're a long way from the original topic here.

> > > For mmio it is my understanding that the "restricted" does the same
> > > already? or is it required in the spec for some reason?
> > 
> > No, it's exactly the same. But I still don't trust driver authors to
> > realise the obvious, or VMM implementations either for that matter.
> > 
> > I'm not sure I see the *harm* in spelling out explicitly for the hard-
> > of-thinking.
> 
> I don't want people to make assumptions, like crashing if device is
> behind an iommu or whatnot.

Why would that happen? If we explicitly document that "on-device memory
access don't go through an external IOMMU that sits all the way over
the other side of the PCI bus between the device and system memory",
which is what I was trying to say...  it doesn't *matter* if the device
is behind an IOMMU or not. It doesn't ever *do* any DMA on the PCI bus.

> We can go with something informative.
> 
> "It is expected that for most implementations, when using this feature,
> the behaviour with and without ACCESS_PLATFORM is the same"

I'd prefer to say nothing. Saying nothing relies on people to do their
thinking and realise that on-device access doesn't cross the PCI bus.
This version actually seems to hint that it's a *choice*, and hints
that it might be OK if the external IOMMU *does* intervene in on-device
memory accesses.


Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)

Powered by blists - more mailing lists