multikernel: support isolated SR-IOV VF assignment

[nickolaev]

Multikernel instances currently lack a complete PCI ownership model. A spawned
x86 kernel needs enough platform and device state to enumerate and operate its
assigned device without exposing or disturbing devices retained by the primary
kernel.

This series adds end-to-end assignment of an SR-IOV VF to a spawned kernel while
the primary retains the PF and enforces DMA isolation.

The series:

1. Adds PCI identity, BAR resources, and host-bridge information to each Multikernel instance.
2. Transfers and restores the x86 ECAM configuration required by the spawned kernel.
3. Exposes assigned devices through synthetic PCI roots instead of enumerating shared physical bridges.
4. Filters configuration-space accesses before hardware access so the spawned kernel cannot probe or modify unassigned functions.
5. Adds exclusive SR-IOV VF leases while keeping the PF bound to its host driver.
6. Makes memory, CPU, PCI, and host-bridge reservation atomic, with reverse-order unwind on failure.
7. Creates a host-owned IOMMU paging domain for each assigned VF and maps only memory owned by the instance.
8. Quiesces and resets the VF before release, then restores its original host driver.
9. Fails closed on IOMMU faults, unexpected device removal, or loss of the VF assignment.
10. Uses the existing x86 Multikernel platform quirk for spawned-kernel timer initialization.

The resulting ownership model is:

• the primary kernel retains the PF and controls the VF assignment lifecycle;
• only SR-IOV VFs can be assigned;
• each VF is exclusively owned by one Multikernel instance;
• the primary owns the VF's IOMMU domain and DMA mappings;
• only instance-owned memory is reachable through DMA;
• the secondary sees its assigned VF through a synthetic PCI root;
• the PF, physical bridges, and unrelated PCI functions are not exposed;
• configuration accesses to unassigned functions do not reach hardware;
• VF identity and BAR resources survive the handoff through owned instance metadata; and
• teardown stops DMA before returning the VF to the host.

Assignment requires an active hardware IOMMU, a singleton IOMMU group, isolated MSI delivery, and a DMA aperture
capable of covering every instance memory region. Instance memory cannot be changed while an IOMMU-backed VF lease is active.

This work can be demonstrated using the main branch here: https://github.com/nickolaev/multikernel

The QEMU harness verifies VF enumeration and traffic in the spawned kernel, continued PF operation in the primary, IOMMU containment,
exclusive ownership, hostile lifecycle operations, repeated create/delete cycles, driver restoration, and fail-closed handling of unexpected VF loss.

It has been tested with qemu-system-x86_64 using Q35, IGB SR-IOV, Intel IOMMU, interrupt remapping, and strict IOMMU mode. It has not yet been tested on real
SR-IOV hardware.

[congwang-mk]

Hi @nickolaev

Nice work, thanks for the PR! I finally have time to look into it.

A few high-level comments:

1. If I understand it correctly, it only works with IOMMU off? This looks a big limitation.
2. VF lifetime is coupled to the PF driver with no coordination
3. Exposed bridges are shared and mutable?
4. For the timer fix, it would be better if we could use existing x86 quirks.

[nickolaev]

@congwang-mk thanks for the high-level review. Indeed, this is a naive implementation of "let's make ICMP pass"; It is very fragile as it is. The questions you asked are setting a proper direction. I have some ideas; let me try to clean things up and will ping you once I have a better patch series.

[nickolaev]

@congwang-mk I have updated the commit history with the revised work and the PR message reflects the new state.
Please take a look when you can.