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

[Peter Xu <peterx@redhat.com>]

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.  I'll put that discussion at last since I
don't know if it's that important.

So taking that e1000 bug into account, 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'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:
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