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_OAAthpLmmyKsXM@infradead.org>
Date: Mon, 7 Apr 2025 00:34:26 -0700
From: Christoph Hellwig <hch@...radead.org>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Christoph Hellwig <hch@...radead.org>, virtio-comment@...ts.linux.dev,
	mst@...hat.com, 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 Fri, Apr 04, 2025 at 10:39:35AM +0100, David Woodhouse wrote:
> >> So "for the emulated devices, just use a device model that doesn't do
> >> arbitrary DMA to system memory" is a nice simple answer, and keeps the
> >> guest support restricted to its *own* standalone driver.
> >
> >It's also one that completely breaks the abstraction. 
> 
> Hm? Having a device that simply doesn't *do* any DMA surely doesn't break
> any system DMA / IOMMU abstractions because it's no longer even relevant
> to them, which is kind of the point.
> 
> Which abstraction did you mean?

Implementing a DMA less device is fine.  Implementing a DMA less virtual
device to work around the lack of CoCo shared bounce buffers in the
system is.

> 
> 
> > I still don't
> >understand what the problem is with having the paravirtualized devices
> >on a different part of the virtual PCIe topology so that the stage2
> >IOMMU isn't used for them, but instead just the direct mapping or a
> >stub viommu that blocks all access.
> 
> It can't have a direct mapping because the VMM can't access guest
> memory. It has to be blocked, which is fine.

I only mentioned direct mapping in not having an IOMMU.  I fully expect
it not to work.

> But that's only part of the picture — then how do you actually get data
> in/out of the device?
> 
> By having on-device memory and not attempting DMA to system memory,
> perhaps...? :)

By implementing the discovery of a shared pool in host memory as
discussed in another branch of this thread?

> >describe this limitation, which is much better than hacking around it
> >using an odd device model.
> 
> It still has the problem that existing drivers in all operating systems
> produced before 2030 will see the device and try to use it as-is, with
> no comprehension of this new thing.

Given how much enablement the various CoCo schemes need it won't work
anyway.

Btw, you mail formatting in the last days went completely crazy.