[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z_N8nk_CpD4v9-VE@infradead.org>
Date: Mon, 7 Apr 2025 00:19:58 -0700
From: Christoph Hellwig <hch@...radead.org>
To: David Woodhouse <dwmw2@...radead.org>
Cc: "Michael S. Tsirkin" <mst@...hat.com>,
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 09:16:44AM +0100, David Woodhouse wrote:
> The sad part is that the system does it all automatically *if* it has
> CONFIG_DMA_RESTRICTED_POOL (e.g. Linux) and the driver never even
> notices that the dma_ops it's using are the swiotlb ops using the
> provided buffer.
>
> Which is *kind* of nice... except that when on a guest OS which *isn't*
> Linux with CONFIG_DMA_RESTRICTED_POOL, the guest will just ignore the
> `restricted-dma-pool` node and try DMA to system memory anyway, which
> will fail.
>
> That's why my proposal adds the negotiated VIRTIO_F_SWIOTLB feature, so
> that the device side can refuse, if the guest *isn't* agreeing to use
> the bounce buffer in the situations where it must do so.
That all assumes the indirect DMA is a device "feature". It's not.
It is a limitation placed on the guest system.
Powered by blists - more mailing lists