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

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

On Thu, Jun 11, 2026 at 02:20:54PM -0400, Peter Xu wrote:
> On Thu, Jun 11, 2026 at 01:02:34PM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jun 11, 2026 at 05:53:54PM +0100, Peter Maydell wrote:
> > > On Thu, 11 Jun 2026 at 17:42, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Thu, Jun 11, 2026 at 05:16:09PM +0100, Peter Maydell wrote:
> > > > > On Thu, 11 Jun 2026 at 16:57, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > Then I'd like to see an example where we have an actual good reason
> > > > > > to do execute arbitrary width accesses on device RAM when the
> > > > > > driver does not execute them, please.
> > > > >
> > > > > That's the case we started with, with this GPU where the
> > > > > virtio data structures are in this PCI BAR. We want the
> > > > > virtio backend to have the freedom to say "I'm just going
> > > > > to assume the ring buffer etc is in RAM, and I don't need to
> > > > > care about carefully ensuring that I only do word accesses".
> > > >
> > > > virtio backend does not need to assume anything. any spec
> > > > compliant guest guarantees it. any address given to
> > > > a virtio device is ram.
> > > 
> > > OK, but how do we tell if the mmap() PCI BAR we have is RAM
> > > or not ? Some of them are, some of them aren't...
> > > 
> > > -- PMM
> > 
> > We don't care? If guest asked a virtio device to access
> > memory then that memory better support accesses guest
> > requested, and on virtio that means any width.
> 
> Yes that's also my understanding that QEMU shouldn't care, if on bare metal
> if it is a grey area with undefined behavior, then QEMU should also be fine
> to make it undefined.
> 
> Only one (IMHO, very slight..) concern is, if such "undefined behavior"
> operation may crash QEMU rather than causing a sigbus like what normally
> would happen on a bare metal.

bus errors are uncommon on bare metal. they aren't usually
handled all that well.

>  I'll put that discussion at last since I
> don't know if it's that important.
> 
> So taking that e1000 bug into account,

Won't the patch I sent resolve e1000 too?

> looks like we have more of such user
> that wants explicit control over the memory operations, likely with
> attibutes:
> 
> - Aligned only
> 
> - No vectored inst
> 
> - No possible duplication (perhaps it means, only use atomic access??? per
>   PeterM's explanation in another email)
> 
> I wonder if we should do this by default to all IOs, I think it might have
> an unwanted impact on general perf.  One idea is we can introduce a new bit
> in MemTxAttrs: say, mmio_strict, which will follow above stricter rule of
> doing IO.
> 
> Then for ram_device, when doing memory access we should also use the same
> set, hence something like:
> 
>   if (memory_access_is_direct(mr, ...)) {
>     if (MemTxAttrs.mmio_strict || memory_region_is_ram_device(mr)) {
>         memmove_strict_mmio(); // or memmove_no_vector(), or ...
>     }
>   }
> 
> I also want to bring us to the same page on differenciating two things:
> 
> - about direct access definition: so far, I want to define this almost as
>   "it is directly accessible from host virtual address space".  It means
>   ram_device definitely falls into this category, so it's a sub-category
>   only but enforces strict mmio as above
> 
> - bounce buffer: I want to make sure we're on the same page this is
>   something totally solving different problem of what we're looking at for
>   ram_device.  Essentially this is only needed if mem is not "direct
>   access".  Otherwise we shouldn't need it (including ram_device).


I think ram_device_direct_access is a hack that should go away.
It's a work around for a memory core bug that we should just fix.



> I'm not sure if above sounds reasonable.  The hope is with that we should
> fix both this GPU and e1000 issues (e1000, and maybe other places, needs to
> start passing MemTxAttrs.mmio_strict, though, if we want to keep the
> default to be still fast-path to use memcpy()/memmove()?).
> 
> Thanks,
> 
> =========================
> 
> Two cases here on the concern:
> 
> (1) if fully emulated device, non-issue afaiu because whatever DMA does
> (with vectored ops) will only apply to QEMU process (like a bounce
> buffer..) so it won't crash,
> 
> (2) if it's a VFIO device (not the GPU case, but when like realtek and some
> guest driver registers it as a DMA target), logically the guest should
> receive a bus error, but for QEMU's case it may crash QEMU with SIGBUS:

what and why would crash qemu?

> sigbus_handler() doesn't process anything except memory failures so far, it
> seems.  The right thing might be that we forward this sigbus to guest, but
> I didn't check further.
> 
> But I don't know if it would really happen, better verify it, and even if
> it will happen I still think it's a very niche security use case to cover
> so far.  Doesn't seem to be a blocker to fix a real perf problem first with
> RAM-like GPU devices.
> 
> -- 
> Peter Xu