Message-ID: <6b3b047f1650d91abe5e523dd7f862c6f7ee6611.camel@infradead.org>
Date: Wed, 02 Apr 2025 16:47:18 +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 Wed, 2025-04-02 at 11:20 -0400, Michael S. Tsirkin wrote:
> On Wed, Apr 02, 2025 at 04:12:39PM +0100, David Woodhouse wrote:
> > On Wed, 2025-04-02 at 10:54 -0400, Michael S. Tsirkin wrote:
> > > > +  If a the device transport provides a software IOTLB bounce buffer,
> > > > +  addresses within its range are not subject to the requirements of
> > > > +  VIRTIO_F_ACCESS_PLATFORM as they are considered to be ``on-device''.
> > > 
> > > I don't get this part. the system designers currently have a choice
> > > whether to have these controlled by VIRTIO_F_ACCESS_PLATFORM or not.
> > > with PCI, for example, BAR on the same device is naturally not
> > > behind an iommu.
> > 
> > In the PCI case this *is* a BAR on the same device, and is naturally
> > not behind an IOMMU as you say. This is just stating the obvious, for
> > clarity.
> 
> Then the platform already does this right, and it's better not to
> try and override it in the spec.

It isn't intended as an "override". This *is* what will happen if the
platform does it right. By mandating it in the spec, the intent is to
reduce the chances of platforms doing it *wrong*? (Or of drivers making
wrong assumptions).

> > For virtio-mmio it also isn't translated by an IOMMU; that was the
> > *point* of the `restricted-dma-pool` support.
> > 
> 
> Clear VIRTIO_F_ACCESS_PLATFORM then?

> I don't want to say that VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_SWIOTLB

> are mutually exclusive...


> Generally, it is preferable to keep all features orthogonal if
> at all possible.

...precisely because they *should* be orthogonal.

VIRTIO_F_ACCESS_PLATFORM defines how system memory is accessed;
basically whether DMA goes through an IOMMU or not. And as you point
out, the "on-device" buffer used with VIRTIO_F_SWIOTLB should never
pass through the IOMMU anyway, so it *is* naturally orthogonal.


And I think it does make sense for both to be set in some cases, for
both physical and virtual devices.


For physical devices that would mean "Got an IOMMU? Sure, go ahead and
use it. If not, if you don't trust me, you can just disable my bus
mastering and just use the SWIOTLB".

It's basically the same for a virtual device. In a confidential compute
model, the device model (in the VMM) might not be *able* to access the
guest memory unless the core guest OS explicitly permits that, through
some kind of pKVM enlightenment to allow pages to be shared, or a
vIOMMU, or marking hardware pages unencrypted. So having both bits set
would mean "Know how to drive that enlightenment? Sure, go ahead and
use it. Otherwise, use the SWIOTLB".

In fact that's exactly what that Linux code for `restricted-dma-pool`
already does — when setting up the dma_ops for the device, if it finds
an actual set of IOMMU operations, it'll use those. And if not, that's
when it falls back to using the provided SWIOTLB.


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

Powered by blists - more mailing lists