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

[David Woodhouse]

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 :)

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