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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Z_Pb3PPIJNp4ZTjY@infradead.org>
Date: Mon, 7 Apr 2025 07:06:20 -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 11:09:54AM +0100, David Woodhouse wrote:
> > Except for all virtual devices.
> 
> Yes, that's what I'm saying.
> 
> And that's also why it's reasonable to have a solution which handles
> this for virtio devices, without necessarily having to handle it for
> *arbitrary* emulated PCI devices across the whole system, and without
> having to change core concepts of DMA handling across all operating
> systems.

Except that you might not have a working two stage iommu everywhere
anyway.  So fix it for real to cover all these cases and skip your
layering violations as a nice little benefit.

> This isn't just about Linux guests, and especially not just about Linux
> guests running running 6.16+ kernels.

That shoudn't matter.  No interface should grow stupid hacks ever just
to support legacy guests.  Get the interface right first and then
implement it in all places you need.

> A solution which can live in a device driver is a *lot* easier to
> actually get into the hands of users. Not just Windows users, but even
> the slower-moving Linux distros.

Don't go there, that just gets us stupid crap like the Intel hiding
NVMe behind AHCI hack or PCIe firmware first error handling.

Get the interface right and then work on making it fit later.

> > 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
> 
> I'm not averse to that, but it's different to the `restricted-dma-pool`
> model that's defined today which has explicit matching. So I'd like to
> reconcile them — and preferably literally use PRP0001 to expose
> `restricted-dma-pool` even under ACPI.

A per-device flag is probably fine and easier for some things like
pool sizing.  It also would be worse for other things like eventually
implementing percpu pools.

> Maybe it's as simple as a flag/property on the `restricted-dma-pool`
> node which declares that it's a 'catch-all', and that *all* devices
> which aren't explicitly bound to an IOMMU or other DMA operations (e.g.
> explicitly bound to a different restricted-dma-pool) should use it?

Yeah.  Similar what we do with the generic shared-dma-pool.

> Either way, we'd still ideally want a virtio feature bit to say "don't
> touch me if you don't understand my DMA restrictions", to prevent older
> drivers (on older operating systems) from failing.

As said before they really need system level awareness of a coco host.
That's not something to be hacked into virtio drivers.