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 05:20:31PM -0400, Peter Xu wrote:
> On Thu, Jun 11, 2026 at 04:52:20PM -0400, Michael S. Tsirkin wrote:
> > 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.
> 
> Ah, not something I was expecting to happen regularly.
> 
> In this case, the whole concern is about a possible malicious guest that
> might have installed a VFIO assigned device MMIO region (which may be
> register based; RAM-based is non-issue) to be a DMA target of anything.
> 
> > 
> > >  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?
> 
> If you mean:
> 
> https://lore.kernel.org/r/20260611093049-mutt-send-email-mst@kernel.org
> 
> Roughly, yes. But it is only to show the idea, not really a real patch?
> 
> I think we need to cover all the rest details (I mentioned all these in my
> previous reply too below):
> 
> - we should better leave memcpy()/memmove() as before for non-ram-device,
>   only do that for ram-devices
> 
> - per PeterM's comment, __builtin_memmove() may still have unwanted side
>   effects (I agree, it looks broken before and maybe we were lucky?)  need
>   to switch to atomics?
> 
> - two spots missing per my previous email here:
> 
>   https://lore.kernel.org/all/aimEl9QQ_LTRPLtd@x1.local/
> 
>   IIUC we should also fix these two, or is it intended to be left?
> 
>   address_space_read()
>   address_space_write_rom()
> 
> > 
> > > 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 didn't find ram_device_direct_access, if you meant ram_device_mem_ops, I
> agree it'll be nice if we can avoid it.

Yes. Simply revert 4a2e242bbb that adds that.

> > 
> > 
> > 
> > > 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?
> 
> If what Alex described issue happened in commit 4a2e242bbb ("memory: Don't
> use memcpy for ram_device regions"), IIUC it will crash qemu, but maybe I
> was wrong.  Alex knows the best.
> 
> So in general, we don't want malicious guest to be able to DoS the host
> process (hence, to me "niche security use case"..).
> 
> Thanks,
> 
> > 
> > > 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
> > 
> 
> -- 
> Peter Xu