virtio: sparse-align initial BAR placement to avoid Windows PnP rebalance deadlock - #8205

Fixes #8202.

Windows 11 25H2's PnP arbiter (pci.sys) rewrites peer BAR addresses on resource rebalance and frequently picks targets that overlap another live device's BAR — see #8202 for the full Microsoft documentation references and the deadlock failure mode. With the default 512 KiB-aligned packed layout, three or four adjacent virtio device BARs at the top of MMIO64 are within Windows' preferred-address window, so the rebalance collides with non-trivial probability (~50% in our reproducer) and move_bar() correctly refuses the conflicting allocation. The guest, having committed the new address to its own state, never reconciles with the rolled-back config register and wedges early boot.

This PR takes the low-risk option #1 from the issue: bump the virtio capability BAR allocator alignment to 8 MiB so initial devices land at well-separated offsets (each 512 KiB BAR consumes 8 MiB of address slack). Windows-side BAR moves now have room to succeed without colliding with other CH-managed devices. On phys_bits=46, the alignment-induced waste is ~64 TiB of unused address space — negligible.

Verified on our testbed: Win11 25H2 boot + vm net --nics 1→2→4→2→1→0 resize chain + 0-NIC snapshot + clone-with-override + chain clone all pass deterministically.

Two commits:

1. virtio: 8 MiB-aligned initial BAR placement — applies to fresh allocation in VirtioPciDevice::allocate_bars(). Both the Memory*BitRegion and the optional shm BAR paths are bumped to 8 MiB alignment.

2. virtio: relax BAR alignment on restore — needed because the guest may have reprogrammed a BAR to a 512 KiB-aligned (but not 8 MiB-aligned) address while running; move_bar() uses CAPABILITY_BAR_SIZE (512 KiB) as its alignment, so any address the guest had settled on must remain valid through snapshot/restore. Without this, every restore from a snapshot of a guest that had moved any BAR fails with Allocating space for an IO BAR failed. Fresh allocation continues to use the sparse 8 MiB alignment.

This is independent of #8203 / #8204 (allocator state leak in move_bar()): even with PR #8204 keeping host-side state consistent, the rebalance attempt still fails when the target overlaps, leaving the guest with an invalid view of the BAR. Sparse layout prevents the rebalance from ever needing to land on an occupied range in the first place.

The issue mentions two alternative fixes (#2 coordinated swap, #3 QEMU-style accept-and-stomp). Both would be more invasive — happy to follow up with those if upstream prefers a deeper fix.

Signed-off-by: CMGS [email protected]