[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250402114757-mutt-send-email-mst@kernel.org>
Date: Wed, 2 Apr 2025 11:51:47 -0400
From: "Michael S. Tsirkin" <mst@...hat.com>
To: David Woodhouse <dwmw2@...radead.org>
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, Apr 02, 2025 at 04:47:18PM +0100, David Woodhouse wrote:
> 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).
The text you wrote makes it seem that even if the platform says use
an IOMMU, it should be bypassed.
> > > 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.
>
I just feel your text for VIRTIO_F_ACCESS_PLATFORM make it
seem like that is not the case.
VIRTIO_F_ACCESS_PLATFORM says a lot of things, e.g. it has implications
for encrypted VMs, and so on.
I would drop this text, and maybe add some clarification in the mmio transport,
as needed.
--
MST
Powered by blists - more mailing lists