machine-arm: pcie-root-port under the SMMUv3 with per-bus stream IDs

[tamnd]

What

-device pcie-root-port on Arm virt, with PCI functions behind it under the SMMUv3, as QEMU 11.1 does it.

• The SMMU now covers the functions behind root ports. Each function's IOMMU region works out its stream ID at each translation from the number its bus has then, as smmu_get_sid() does with PCI_BUILD_BDF(pci_bus_num(bus), devfn). Before this the stream ID was fixed when the function was plugged. SmmuV3::device_ops_with takes the stream ID as a closure; device_ops(sid) still works and calls it.
• The root port itself gets an IOMMU region too, as pci_init_bus_master() gives it one in QEMU.
• The IORT root complex mapping covers the root bus and the buses behind the bridges (iort_host_bridges() with pci_bus_range()).
• As in virt_acpi_build_update(), the ACPI tables, loader and RSDP are built again on the first fw_cfg read after each reset, so the IORT has the bus numbers the firmware gave the root ports. A reset clears the flag, as virt_acpi_build_reset() does.
• The DSDT nests the functions behind a cold plugged root port in the port's device (build_pci_bridge_aml()).
• -device pcie-root-port takes id, bus=pcie.0, addr, chassis, slot, port, hotplug and multifunction. PCI types take bus=<root port id>. The other QEMU properties of the type fail with "is not supported by ruvm yet".

The shared notifier API is not touched. The only change in hw-iommu is device_ops_with in smmuv3.rs.

Comparison with QEMU 11.1

Alpine linux-virt 6.12.110 with -M virt,iommu=smmuv3,gic-version=3 -cpu max -m 1G -smp 1 -device pcie-root-port,id=rp1,chassis=1 -device virtio-blk-pci,bus=rp1,drive=d0,disable-legacy=on,iommu_platform=on, booted both with -kernel Image (device tree) and with edk2 and -kernel vmlinuz-virt (ACPI). The initramfs prints the SMMU and IOMMU dmesg lines, the PCI functions with their IOMMU groups, the IORT, the md5 of the 16 MiB disk, then writes a sector, drops the caches, reads it back, and prints the md5 again.

Results, ruvm against QEMU 11.1:

• SMMU probe lines match in both boots: ias 44-bit, oas 44-bit (features 0x00088705), 262144 cmdq entries, 131072 evtq entries.
• The IORT read from /sys/firmware/acpi/tables/IORT is the same 0xec bytes on both, with the root complex mapping IDs 0 to 0x1ff (buses 0 and 1) to the SMMU.
• IOMMU groups: with the device tree the root port and the disk behind it share group 0 on both. With ACPI the disk gets a group of its own on both.
• The disk reads md5 3cf64d06... before, the sector written through the SMMU reads back, and the md5 after is b6fb6854... on both, in the guest and on the host image.
• The one difference is that QEMU adds its default NIC at 00:01.0, so its root port is 00:02.0 and its group numbers count one more. ruvm has no default NIC on virt.

A first ruvm run with -smp 2 stalled in multi_cpu_stop with soft lockups after the SMMU probe, on a server with a load of about 25 on 6 cores. With -smp 1 the same point took about 45 s and then went on. I did not check whether main does the same.

Differences from QEMU, not done here

• pcie-root-port without an id fails. QEMU names its bus pcie.<n> with an n that depends on the other buses, so nothing can be plugged behind it by name anyway.
• A root port behind a root port, and the other root port properties (the reserve sizes, x-speed, acpi-index and so on), fail with "not supported by ruvm yet".
• Root ports together with virtio-iommu fail in either order, since the virtio-iommu endpoints are only set up for the root bus. That is a follow-up.
• pci-bridge and pcie-pci-bridge are not ported, so the requester ID aliasing of pci_device_get_iommu_bus_devfn() is not needed yet.
• sbsa-ref does not take pcie-root-port yet.
• Accelerated nested mode (accel=on, CMDQV) needs host SMMU hardware we do not have, so it comes last. Notifiers and replay will build on the IOMMU notifier API from hw-vfio, intel-iommu: DMA through the vIOMMU for vfio-pci #330.

Tests

• smmu_stream_id_behind_a_root_port: with the stream table entry of stream 0 bypassing and the entry of 0x100 aborting, the MSI of a function plugged while its bus was 0 is dropped once the guest numbers the bus 1, and gets through with the SMMU off.
• iort_behind_a_root_port: the IORT maps 0x200 IDs to the SMMU with the bus numbered 1. Read through fw_cfg it keeps the numbers of its first read until the next reset, then has 0x400 for buses 1 to 3. The DSDT has S00 inside S10.
• root_port_and_virtio_iommu, and planner tests for the properties and errors.
• On this commit rebased onto 31dd93b, on server2: cargo test -p ruvm-hw-iommu -p ruvm-machine-arm -p ruvm-system -p ruvm-hw-pci -p ruvm-firmware -p ruvm-mem, cargo test -p ruvm-system --lib, the linux-user x86 suite, clippy -D warnings, cargo check --workspace --all-targets, the xtasks and the Windows check all pass.