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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 10, 2026 at 03:10:46PM -0400, Peter Xu wrote:
> On Wed, Jun 10, 2026 at 12:19:39PM -0400, Michael S. Tsirkin wrote:
> > On Wed, Jun 10, 2026 at 05:11:40PM +0100, Peter Maydell wrote:
> > > On Wed, 10 Jun 2026 at 16:37, Peter Xu <peterx@redhat.com> wrote:
> > > >
> > > > On Wed, Jun 10, 2026 at 10:06:24AM -0400, Michael S. Tsirkin wrote:
> > > > > This is the change that broke it I think?
> > > > >
> > > > >
> > > > > commit 4a2e242bbb306ef5c16ce9e7bb2da3bd8a4eb098
> > > > > Author: Alex Williamson <alex@shazbot.org>
> > > > > Date:   Mon Oct 31 09:53:03 2016 -0600
> > > > >
> > > > >     memory: Don't use memcpy for ram_device regions
> > > > >
> > > > >
> > > > > Maybe Alex has an opinion on what to do.
> > > >
> > > > I can offer one idea here..
> > > >
> > > > IIUC the major issue was vector ops but the mr ops might be too heavy, then
> > > > another way to fix it is in memory API instead of using memcpy()/memmove(),
> > > > we always use a helper (say, memmove_no_vector()) to do the split and
> > > > properly aligned IOs as what ram_device_mem_ops does right now, this should
> > > > only applies to ram_device.
> > > 
> > > If the underlying memory needs to be accessed only with specific
> > > alignment/size, as the 4a2e242bbb30 commit message suggests, then
> > > we cannot expose it via address_space_map(), so we must have
> > > a bounce-buffer.
> 
> I get the point; this is technically a concern, but IMHO it's still
> slightly different, and I expect it non-issue in reality.
> 
> Essentially we can have two ways to iteract with the pci bar:
> 
> 1) via vCPU / CPU access
> 2) via DMA targets
> 
> Alex can correct me, but IIUC that problem was when the CPU accesses the
> mapped region with memcpy(), rather than making that bar to be DMA target.
> Hence, use case 1) only.  So my current understanding is the proposal
> shouldn't (hopefully..) regress that realtek problem because use case 1) is
> properly covered.
> 
> I always think it is very bogus to have any register-like MMIO regions to
> be passed over, maybe it's a bug already?  It's because I don't know any
> way to guarantee DMA performs in a way that will be compatible with a pci
> bar that is register-based and will not have any side effect.  Say, if some
> pci bar (real register-backed) must be accessed in 4B and aligned, how
> would a DMA request guarantee that?
> 
> >From that perspective, IMHO it's a guest (driver or app, I'm not sure..)
> bug to make such region to be DMA target in the first place.  The outcome
> of such setup should be undefined.  It'll be the same after applying the
> proposal I raised, that QEMU will have undefined behavior for such pci bars
> to be used as DMA targets.
> 
> Thanks,

Sorry, wasting gibabytes and GB/s of main
RAM and PCI BW just to shuffle data back out the PCI bus
is out of the question.

You don't have to like it)

> > 
> > Right. And virtio currently isn't friendly to the bounce buffer.
> > We can fix that but I worry about the perf impact.
> > 
> > > The address_space_map() function says
> > > "here's a host pointer to  memory, do what you like to it", and
> > > the caller is entitled to memcpy to/from it or otherwise
> > > access it with any C operations, which are not guaranteed to
> > > respect any kind of alignment or similar restrictions.
> > > 
> > > My guess from commit 4a2e242bbb30 is that that applied an
> > > overly broad "don't do direct access" hammer to all
> > > vfio assigned devices, and that there needs to be some
> > > concept of "this vfio assigned device's region is OK for
> > > direct access" vs "this other one is not", such that if
> > > this GH100 card's BAR guarantees it can be treated entirely
> > > as RAM then we can have memory_region_supports_direct_access()
> > > return true for it.
> > > 
> > > thanks
> > > -- PMM
> > 
> 
> -- 
> Peter Xu