[tamnd]

Part of #9.

What

iommu_platform on the virtio-mmio devices of Arm virt (-device virtio-*-device,iommu_platform=on), as QEMU 11.1 takes it. Before this, -device virtio-blk-device,iommu_platform=on failed with "Property 'virtio-blk-device.iommu_platform' not found".

• No IOMMU sits in front of the virtio-mmio transports, and the virtio-mmio bus has no get_dma_as. So, as in virtio_bus_device_plugged(), the device offers VIRTIO_F_IOMMU_PLATFORM and does its DMA in system memory.
• The transport is legacy by default, and a legacy transport shows only the low 32 feature bits, so the guest sees the bit only with -global virtio-mmio.force-legacy=false. That matches virtio_mmio_read().
• VirtMachine::attach_virtio_with and attach_virtio_at_with take the property. attach_virtio and attach_virtio_at call them with it off.
• The module docs of virt.rs had an over-long line from machine-arm: pcie-root-port under the SMMUv3 with per-bus stream IDs #336, which is reflowed here.

Comparison with QEMU 11.1

The same Alpine 6.12 guest booted on QEMU 11.1 and on ruvm with -M virt,iommu=smmuv3,gic-version=3 -cpu max -m 1G -smp 1 (plus -nodefaults in the force-legacy=false runs, which ruvm needs for -global) and -device virtio-blk-device,drive=d0,iommu_platform=on over a 16 MiB raw image. It loads virtio_mmio and virtio_blk, prints the device features from sysfs, takes the md5 of /dev/vda, writes a sector, drops caches, reads it back and takes the md5 again.

Run	QEMU 11.1	ruvm
DT, legacy transport (default)	bits 32 and 33 clear	same features string
DT, -global virtio-mmio.force-legacy=false	bits 32 (VERSION_1) and 33 (ACCESS_PLATFORM) set	same features string
ACPI (edk2), force-legacy=false	bits 32 and 33 set, parent LNRO0005:1f	same features string, same parent

In all runs the md5 before the write was 95934ad229a3114a0de2dc62cee94d4e, the sector read back as written, and the md5 after the write was 269d53a2fae97c0c7de47a8a3d6776b2 in the guest and on the host image, on both emulators. The ruvm boots used a release build of this diff on debd8d2; #339 and #340, which came in after, do not touch the virtio-mmio path.

Not done here

• riscv virt still takes iommu_platform only on its PCI types.
• SMMUv3 notifiers and replay on the hw-vfio, intel-iommu: DMA through the vIOMMU for vfio-pci #330 API come next, then RMR, ATS, secure state and VMState. Accelerated nested mode (accel=on, CMDQV) needs host SMMU hardware we do not have, so it comes last.

Tests

• virtio_mmio_iommu_platform: the high feature word shows VIRTIO_F_IOMMU_PLATFORM on a modern transport with the property, not without it, and shows nothing on a legacy transport.
• A planner test for virtio-rng-device,iommu_platform=on.
• On ad204ac plus this diff, on Linux x86_64: cargo fmt --check and clippy -D warnings on machine-arm, system and hw-virtio; cargo check --workspace --all-targets; cargo test -p ruvm-system --lib (113 passed); the tests of machine-arm, system, hw-virtio, hw-iommu and hw-pci, and the linux-user x86 suite (user-common, linux-user, jit-x86_64, jit-core), 729 passed and 0 failed in all; the provenance, unsafe-audit, layers and style xtasks; cargo check --target x86_64-pc-windows-msvc on machine-arm and system with no warnings.