linux-kernel - Re: [RFC PATCH 3/3] transport-pci: Add SWIOTLB bounce buffer capability

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: <228b84cf77d3dfe6c4a80a68c051d530286e1f55.camel@infradead.org>
Date: Thu, 03 Apr 2025 09:44:41 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: "Michael S. Tsirkin" <mst@...hat.com>
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,  Zhu Lingshan
 <lingshan.zhu@....com>
Subject: Re: [RFC PATCH 3/3] transport-pci: Add SWIOTLB bounce buffer
 capability

On Thu, 2025-04-03 at 03:27 -0400, Michael S. Tsirkin wrote:
> 
> So on the PCI option. The normal mapping (ioremap) for BAR is uncached. If done
> like this, performance will suffer. But if you do normal WB, since device
> accesses do not go on the bus, they do not get synchronized with driver
> writes and there's really no way to synchronize them.
> 
> First, this needs to be addressed.

I was assuming the bounce buffer region would generally be in a BAR of
its own. Would a write-combining mapping not suffice?

In the case of a virtual device where the hypervisor *knows* it's all
just host memory anyway and is cache-coherent, doesn't the hypervisor
get to just make it normally cached anyway, regardless of what the
guest asks for? I forget all the bizarre rules about guest/host PAT
combinations now, and that's just x86 anyway...

I think it's OK to have a feature which makes more sense for a virtual
device than it does for a physical device.

For example, it doesn't make any sense for a physical device *not* to
have VIRTIO_F_ACCESS_PLATFORM, does it? That is only possible because
virtual devices are "special" and can have the bug^Wmicro-optimisation
of which we spoke.

The intended use case for this bounce buffering *is* more targeted at
virtual devices than physical, and yes, it'll probably perform better
on virtual devices than physical too.

But if a physical device finds itself in a system where it actually
*cannot* do DMA to system memory, and provides this bounce-buffer...
then however slow it is, it's still going to have better performance
than the complete lack of functionality that would otherwise result :)

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)