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

[David Woodhouse]

On 4 April 2025 07:29:02 BST, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>On Thu, Apr 03, 2025 at 09:10:41AM +0100, David Woodhouse wrote:
>> Thanks. I'll take a closer look at handling that. I think it's
>> reasonable for the negotiation of the VIRTIO_F_SWIOTLB feature to be
>> the thing that switches *all* addresses to be on-device, and the on-
>> device buffer can't be accessed unless VIRTIO_F_SWIOTLB has been
>> negotiated.
>> 
>> Which neatly sidesteps the original thing I was trying to clarify
>> anyway.
>
>Switching all addressing does not sound like a good idea.  The main
>thing these indirect buffers are used for is as a staging points for
>P2P DMA, in which case they often are only used for some transfers or
>even parts of a transfer.  At least for physical virtio devices P2P
>is probably not far off with the current GPU craze, and I wouldn't
>be surprised if people found uses for paravirt P2P as well.

That isn't the original use case I had for it in virtio but that's useful input, thanks.

Plumbing a 65th address space bit through all descriptors seems impractical. Would it suffice for the driver to *specify* the location in the device's DMA address space that the on-device buffer appears, to allow it to avoid conflicts with system memory addresses? Better ideas?