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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z_OVbRNHU1LXU368@infradead.org>
Date: Mon, 7 Apr 2025 02:05:49 -0700
From: Christoph Hellwig <hch@...radead.org>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Christoph Hellwig <hch@...radead.org>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	virtio-comment@...ts.linux.dev, 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 Mon, Apr 07, 2025 at 08:54:46AM +0100, David Woodhouse wrote:
> On Mon, 2025-04-07 at 00:30 -0700, Christoph Hellwig wrote:
> > On Fri, Apr 04, 2025 at 12:15:52PM +0100, David Woodhouse wrote:
> > > We could achieve that by presenting the device with a completely new
> > > PCI device/vendor ID so that old drivers don't match, or in the DT
> > > model you could make a new "compatible" string for it. I chose to use a
> > > VIRTIO_F_ bit for it instead, which seemed natural and allows the
> > > device model (under the influence of the system integrator) to *choose*
> > > whether a failure to negotiate such bit is fatal or not.
> > 
> > Stop thinking about devices.  Your CoCo VM will have that exact same
> > limitation for all devices, because none of them can DMA into random
> > memory.
> 
> Nah, most of them are just fine because they're actual passthrough PCI
> devices behind a proper 2-stage IOMMU.

Except for all virtual devices.

> > > Then the OS would need to spot this range in the config space, and say
> > > "oh, I *do* have a swiotlb pool this device can reach", and use that.
> > 
> > Yes, that's largely how it should work.
> 
> The problem in ACPI is matching the device to that SWIOTLB pool. I
> think we can expose a `restricted-dma-pool` node via PRP0001 but then
> we need to associate a particular device (or set of devices) to that
> pool. In DT we do that by referencing it from a `memory-region` node of
> the device itself.

I don't think you actually _need_ to have an explicity device vs pool
match.  All pools in host memory (assuming there is more than one)
should be usable for all devices bar actual addressing limits that are
handled in the dma layer already.  The only things you need is:

 a) a way to declare one or more pools
 b) a way to destinguish between devices behind a two stage IOMMU vs not
    to figure out if they need to use a pool