[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z-46TDmspmX0BJ2H@infradead.org>
Date: Thu, 3 Apr 2025 00:35:40 -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 Thu, Apr 03, 2025 at 08:28:19AM +0100, David Woodhouse wrote:
> Linux has 'SWIOTLB' support, but I didn't see it as a term specific to
> that particular implementation; it seemed like a concept would would be
> understood elsewhere. But sure, I'm happy to rename it to just 'bounce
> buffers' or something like that. I'll see what I can come up with that
> is succinct enough to use in VIRTIO_F_xxx and VIRTIO_PCI_CAP_xxx names.
I think you still miss the point.
What you describing is either:
1) A BAR (or BAR-like region on MMIO) that can be used to stage
indirect I/O
and
2a) a device that doesn't have any DMA capabilities, but instead
requires use for the above staging region
and/or
2b) a system configuration where devices are prevented from accessing
guest memory
1) makes perfect sense in virtio. It is the equivalent of the NVMe CMB
and similar features on various devices.
2a) would make sense if we actually have such devices and not just
system configs, which I doubt.
2b) is the job of ACPI or DT to communicate, not that of virtio
Powered by blists - more mailing lists