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_N-DaeAvSuSMJJI@infradead.org>
Date: Mon, 7 Apr 2025 00:26:05 -0700
From: Christoph Hellwig <hch@...radead.org>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: David Woodhouse <dwmw2@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	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 Fri, Apr 04, 2025 at 06:37:16AM -0400, Michael S. Tsirkin wrote:
> some embedded devices can have addressing restrictions, such
> as the number of bits of an address.
> In another example, the legacy balloon device only supports addresses
> up to 48 bit.
> These can still be useful if driver does not use the inaccessible
> addresses.

Let's not mix that up.  The DMA API handles addressing limitations
just fine, which is totally different of only allowing access to
a specific region no matter where it sits.

> Now, a question: DMA API under linux at least, can actually work
> around device limitations using a bounce buffer. It does, however,
> need to know what to work around.
> So, maybe the device needs to expose a range?
> But what is the range in your case?
>  
> 
> Maybe the new registers list the range of addresses device can access,
> and driver promises to be within that range by negotiating the
> feature bit?

We do not have an issue with a device here.  We have a system design
that does not allow devices or the hyper visor to access random guest
memory, and because of that DMA or the virtual or physical kind needs
to go through a designated area that is accessible outside the guest.

Trying to frame this as a device limitation is already causing so much
trouble in this thread and it will just get worse.