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: <b51f10a019038fb5219149c86d8a977879975cf4.camel@infradead.org>
Date: Wed, 02 Apr 2025 16:21:09 +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
Subject: Re: [RFC PATCH 3/3] transport-pci: Add SWIOTLB bounce buffer
 capability

On Wed, 2025-04-02 at 10:58 -0400, Michael S. Tsirkin wrote:
> On Wed, Apr 02, 2025 at 12:04:47PM +0100, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@...zon.co.uk>
> > 
> > Add a VIRTIO_PCI_CAP_SWIOTLB capability which advertises a SWIOTLB bounce
> > buffer similar to the existing `restricted-dma-pool` device-tree feature.
> > 
> > The difference is that this is per-device; each device needs to have its
> > own. Perhaps we should add a UUID to the capability, and have a way for
> > a device to not *provide* its own buffer, but just to reference the UUID
> > of a buffer elsewhere?
> 
> Such uuid appoach will be really messy with physical devices.

Yes, although it could work with multifunction devices all sharing a
SWIOTLB buffer that just *one* of the functions provides. Although in
that case, it's simpler just to add a function number as well as the
existing BAR#/offset/length of the virtio_pci_cap.

> Also messy with confidential since config space is not encrypted.

It's messy on the guest side too, as both provider and consumers of the
same SWIOTLB buffer have to be in the same IOMMU group and can't be
shared to different (nested) guests or userspace VFIO users.

> Really, if you want something complex like this, just use virtio-iommu.
> It does not require parsing page tables or anything complex like that.
> The attraction of the same BAR proposal is that it is, at least, simple.

Agreed. I think the simple option of a device having its *own* SWIOTLB
region makes most sense, without overengineering a sharing model.

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