Re: [PATCH RFCv1] virtio: Inherit max bounce buffer size from bus parent if possible

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3040 bytes --]

On Thu, Jun 11, 2026 at 11:09:35AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jun 11, 2026 at 04:04:20PM +0100, Peter Maydell wrote:
> > On Thu, 11 Jun 2026 at 15:46, Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Thu, Jun 11, 2026 at 10:20:22AM -0400, Stefan Hajnoczi wrote:
> > > > Gavin posted the lspci output:
> > > >
> > > >   Region 0: Memory at 661ffd000000 (64-bit, prefetchable) [size=16M]
> > > >   Region 2: Memory at 662000000000 (64-bit, prefetchable) [size=128G]
> > > >   Region 4: Memory at 661ffe000000 (64-bit, prefetchable) [size=32M]
> > > >
> > > > These are prefetchable memory BARs, so I would expect them to be
> > > > mmappable. Why does QEMU have no way of knowing upfront whether they can
> > > > be mmapped?
> > >
> > >
> > > They can be mmapped.  The issue is just that after mmap flatview uses
> > > memcpy/memmove on them, and that might not match what guest driver is
> > > expecting specifically for 1/2/4/8 byte accesses.
> > 
> > Huh? The guest driver has nothing to do with it, surely.
> 
> My answer is I don't know.
> 
> But the commit that introduced the regression says:
> 
> 	 The assumption here is that accesses initiated by the VM are
> 	    driven by a device specific driver, which knows the device
> 	    capabilities. 
> 
> > The
> > problem is that for some PCI devices (like the network card
> > mentioned in 4a2e242bbb30's commit message) the BAR is *not*
> > safe for arbitrary access (because the actual real host hardware
> > inside it is not RAM).
> 
> But we don't do arbitrary access. Why would we?
> 
> > That commit disabled direct access
> > for all vfio MRs, which is safe but overcautious. Would
> > "direct access is OK if this is a prefetchable memory BAR" be OK?
> > Or do some prefetchable memory BARs still have restrictions
> > beyond those of real RAM?

I wonder the same thing.

> > 
> > > Removing mmap is one solution, this is what vfio does now.
> > > Fixing flatview is another.
> > 
> > No, you can't fix this in flatview. If a BAR is not safe for
> > direct access then it is not safe for direct access.
> > 
> > -- PMM
> 
> There's no such thing as "not safe for direct access" in PCI.
> All operations are memory operations.
> What can be unsafe is accesses of specific width and length.
> 
> So we should not use variable length memcpy/memmove which
> do that. Fixes length memcpy/memmove exactly mimic what
> guest does, so they are safe.

The bounce buffer approach doesn't seem like a solution to me: if the
device has alignment and size restrictions on accesses, then the bounce
buffer won't get them right because it doesn't know where the registers
live within the BAR.

Also, the guest initiated I/O to a VIRTIO device pointing to a buffer in
another PCI device's BAR. In this case any failure to handle BAR
accesses would be the guest's problem. It cannot assume that the VIRTIO
device follows a specific DMA transfer pattern with respect to
alignment/size.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]