Re: [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use of SWIOTLB bounce buffers

[David Woodhouse]

On Thu, 2025-04-03 at 15:31 +0800, Zhu Lingshan wrote:
> On 4/3/2025 3:24 PM, David Woodhouse wrote:
> > On Thu, 2025-04-03 at 15:13 +0800, Zhu Lingshan wrote:
> > > Hello David
> > > 
> > > IMHO, if we need a bounce buffer, why not place it on the host memory?
> > As explained in the cover letter, this is designed for the case where
> > the device *cannot* easily access host memory.
> 
> Do you mean CoCo encrypted memory? If so, what is the difference between
> the host memory side bounce buffer and a device memory bounce buffer
> to a guest except the transport(DDR or PCI)? The device should be
> able to access host memory side bounce buffer.

In the CoCo case, yes. As long as it's *known* to be memory which is
shared with the hypervisor, and unsuspecting guests won't accidentally
use it as general purpose RAM, then pKVM (or whatever) can happily
allow Linux and the VMM to access it.

That's basically how it works for virtio-mmio, as I just mentioned in a
different subthread. The region referenced by `restricted-dma-pool` is
in the guest memory address space, and the "platform" is configured to
allow DMA *only* there.

Doing the same on the PCI transport (referencing an address range in
system address space rather than on the device itself) is slightly
unnatural, but as I said if we consider it the responsibility of the
firmware to *program* that then we could maybe squint and accept it
even in the case of physical devices. I'm not sure I like it much
though.

Attachment: smime.p7s
Description: S/MIME cryptographic signature