Re: [PATCH v1] hw/pci: Add PCI MMIO Bridge for device-to-device MMIO

[Alex Williamson <alex@shazbot.org>]

On Wed, 3 Dec 2025 14:18:17 -0700
Stephen Bates <sbates@raithlin.com> wrote:

> This patch introduces a PCI MMIO Bridge device that enables PCI devices
> to perform MMIO operations on other PCI devices via command packets. This
> provides software-defined PCIe peer-to-peer (P2P) communication without
> requiring specific hardware topology.

Who is supposed to use this and why wouldn't they just use bounce
buffering through a guest kernel driver?  Is rudimentary data movement
something we really want/need to push to the VMM?  The device seems
inherently insecure.

> Configuration:
>   qemu-system-x86_64 -machine q35 \
>       -device pci-mmio-bridge,shadow-gpa=0x80000000,shadow-size=4096
> 
> - shadow-gpa: Guest physical address (default: 0x80000000, 0=auto)
> - shadow-size: Buffer size in bytes (default: 4096, min: 4096)
> - poll-interval-ns: Polling interval (default: 1000000 = 1ms)
> - enabled: Enable/disable bridge (default: true)

Wouldn't it make more sense if the buffer were allocated by the guest
driver and programmed at runtime?  Polling just adds yet more
questionable VMM overhead, why not ioeventfds?

> The bridge exposes shadow buffer information via a vendor-specific PCI config
> space:
> 
>   Offset 0x40: GPA bits [31:0]
>   Offset 0x44: GPA bits [63:32]
>   Offset 0x48: Buffer size
>   Offset 0x4C: Queue depth

Arbitrary registers like this should be exposed via BARs or at least in
a vendor specific capability within config space.

...
> +
> +VFIO can only map guest RAM not emulated PCI MMIO space. And, at the present

only guest RAM: False, not emulated PCI MMIO: True

> +time, VFIO cannot map MMIO space into an IOVA mapping. Therefore the PCI MMIO

Other assigned device MMIO, it absolutely can.  The legacy type1 support
has always had this and IOMMUFD based vfio is about to gain this via
dma-buf sharing as well.  Thanks,

Alex