[RFC] Generic platform device support via vfio-user

[Thomas Berger <loki+qemu@loki.codes>]

[-- Attachment #1: Type: text/plain, Size: 4199 bytes --]

Hi all,

I want to propose generic platform device support for embedded systems
using vfio-user as the backend interface.

Problem
-------

QEMU's device discovery mechanisms (Device Tree, ACPI, PCI enumeration)
don't work for bare-metal embedded systems. Instead, board configurations
are hardcoded: memory regions, IRQ assignments, and device wiring are all
in board realize() code.

The ARMv7-M market alone has thousands of microcontroller variants (STM32,
Nordic, NXP Kinetis, Infineon, TI, Microchip, etc.), each with different
peripheral addresses and IRQ mappings. Supporting all these variants with
individual board files doesn't scale.

Even providing generic boards with external peripheral definitions [1] only
solves part of the problem:

Vendor peripherals (RCC, power management, DMA controllers, custom timers,
etc.) vary heavily between vendors and product lines. Maintaining hundreds
of peripheral implementations in QEMU is not sustainable.

Beyond functional emulation, firmware testing requires realistic timing,
blocking I/O, and side-effects across MCU variants. QEMU has the
infrastructure (TCG plugins, GDB integration, vfio) but lacks device
coverage.


Proposed Solution
-----------------

I propose leveraging the existing vfio-user infrastructure to delegate
vendor-specific peripheral implementation to external projects, while
keeping board topology management in QEMU.

A vfio-user-platform device would provide standard peripherals (UART, I2C,
etc.), but there's a challenge: The vfio-user protocol (based on kernel
vfio) has no mechanism to communicate required MMIO addresses and IRQ
numbers. Kernel vfio-platform devices inherit these from Device Tree,
which doesn't exist in bare-metal embedded systems.


Why not extend the vfio-user protocol?
---------------------------------------

While protocol extension is possible, it would cause QEMU's protocol to
diverge in a critical area (memory region definition) for a narrow use
case (embedded platforms without DT). The interaction between board and
device would still lack a clean mechanism.


Board-integrated vfio-user-platform device
-------------------------------------------

An alternative approach would be a vfio-user-platform device that is NOT
user-instantiable via `-device`. Instead, board code creates and
configures it during initialization.

The device connects to an external backend via Unix socket (board
property), handles vfio-user protocol negotiation, and exposes MMIO
regions and IRQs for the board to wire into the system.


Control region for device metadata
-----------------------------------

To enable board-device communication without protocol extension, the
vfio-user backend could provide a control region (Region 0) containing
device metadata: MMIO addresses, IRQ numbers, and capabilities. The board
reads this during initialization to properly wire the device into the
system.


System-control devices
-----------------------

Some peripherals have system-wide side-effects (e.g., RCC clock trees) and
may need to modify QEMU internals like clock frequencies used by other
peripherals. This would require special handling beyond standard MMIO
forwarding.


Alternatives considered
-----------------------

Instead of using device-provided memory region addresses and IRQs, the
board could be configured with a user-provided configuration to map those
devices. However, the most common use cases for such a vfio-platform
device are:

- Providing a single device not implemented in QEMU
- Providing the whole peripheral stack

In both cases, the user would need to create a configuration file either
for a single MMIO region, or containing multiple regions with gaps and
offsets for a singular backend device.


Questions
---------

What are your thoughts on this approach?

If this would be an acceptable concept, I am willing to write and provide
a PoC implementation for further discussion.

As I am new to the QEMU code base, any guidance, hints, or known pitfalls
in this area I should know about?

Thanks in advance,
Thomas

---
[1] CMSIS SVD based peripheral definitions in GNU ARM Eclipse QEMU:
    https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg03544.html

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]