fix(qemu-acpi): emit ACPI PCI hotplug AML for root-port buses - #1203

Problem

A TDX CVM with GPUs behind pcie-root-ports and ACPI PCI hotplug enabled (the default; hotplug_off = false) fails lite ACPI verification. A captured attestation from an 8×B200 CVM (QEMU 10.2.1, dstack-0.6.0-rc3) fails verifier-v0.6.0-rc3 with:

TDX lite acpi-loader digest mismatch:
  expected adae98e24401f6c8d6f3f2c24a78023ebc3c82ed951a92dde7958e5eae1fe1b4352ad1075aec822b687469075027b82c
  reported 01f02cba34d8f7213872ce341a587c636016a6268d0b9c2d2198058a8a709fe38cde80f67c808067444cb8fa11cdd27c

Root cause: once a root port's secondary bus is ACPI-hotplug capable, QEMU gets a BSEL for it (acpi_set_bsel) and adds hotplug AML to the DSDT. The generator emitted none of it:

• per root port: BSEL, a Scope (S00_) with ASUN/_DSM/_SUN/_EJ0, and a DVNT method (build_pci_bridge_aml → build_append_pcihp_slots);
• a \_SB.PCI0.PCNT tree that selects each bus and notifies it (build_append_notification_callback);
• a non-empty _GPE._E01 that calls \_SB.PCI0.PCNT under BLCK whenever a PCNT exists.

Fix

• notify.rs: when hotplug is on, emit the hotplug AML for each pcie.0 root port, plus the PCNT scope. BSEL values run in reverse slot order because QEMU inserts each secondary bus at the head of the parent's child list (QLIST_INSERT_HEAD in pci_bridge_initfn) and assigns BSEL depth-first.
• gpe.rs: _E01 acquires BLCK, calls PCNT, and releases BLCK when a PCNT exists. Otherwise it stays empty, as before.
• PXB-attached root ports (hugepage/NUMA mode) get no AML. QEMU's expander-bridge DSDT node does not enumerate children ("Expander bridges do not have ACPI PCI Hot-plug enabled").
• The helper documents the dstack-vmm device order the BSEL mapping depends on: ascending root-port slots, one function per port, and PXBs created before root ports.

QEMU version coverage

I extracted every QEMU function involved from the upstream tags and compared them after stripping comments and whitespace:

So the new AML is version-independent across the supported range and needs no compatibility-profile gating.

Verification

• Replayed the captured 8×B200 attestation through verifier-v0.6.0-rc3 plus this change. Only one other input differs from the capture: pci_hole64_size is set to the 64-bit window the guest actually saw (see the note below). With that, all four checks pass: quote, event log, OS image hash, and ACPI (is_valid: true, tcb_status: UpToDate).
• tdx_lite_acpi_matches_captured_eight_gpu_qemu_10_2_vm pins all three RTMR0 ACPI digests (loader, RSDP, tables) from that CVM's event log. The loader digest alone only proves table sizes and offsets; the tables digest proves the AML bytes.
• cargo test -p qemu-acpi (46 passed), cargo test -p dstack-verifier tdx_lite_acpi (5 passed), clippy clean.

Not covered: no QEMU-generated fixture with root ports and endpoints exists yet. The byte-level evidence for versions other than 10.2.1 is the source comparison above. A follow-up should add a root-port + endpoint topology to scripts/differential-upstream.sh.

Known gap (follow-up, not in this PR)

The DSDT _CRS 64-bit window is max(firmware-assigned BAR range, start + pci-hole64-size) (q35_host_get_pci_hole64_end). With the default pci_hole64_size = 0, QEMU uses a 32 GiB hole, but eight B200s need roughly 3.75 TiB of BAR space. The real window (0x380000000000-0x3bc006013fff) therefore cannot be derived from vm_config, and the tables digest still mismatches in production. Possible fixes:

• GPU hosts configure a 1 GiB-aligned qemu_pci_hole64_size larger than the BAR span;
• the VMM sizes the hole automatically;
• the verifier rejects num_gpus > 0 && pci_hole64_size == 0 with a clear error.

Separately, the generator ignores QEMU's 1 GiB round-up of start + pci_hole64_size.

Co-authored with @Leechael, who wrote the qemu-acpi change.