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 13-patch series:

1. Adds PCI identity, BAR resources, and host-bridge information to each Multikernel instance.
2. Routes spawned-kernel PCI configuration accesses through the primary, which validates the sender and active VF lease before accessing hardware.
3. Exposes assigned devices through synthetic PCI roots instead of enumerating shared physical bridges.
4. Filters raw x86 PCI configuration operations so only assigned functions can be requested through the host control plane.
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 and before instance restart, then restores its original host driver on release.
9. Forces an instance to halt on unexpected PF or VF loss.
10. Passes the primary kernel's timer calibration state to spawned x86 kernels.
11. Keeps MSI/MSI-X allocation and interrupt-remapping ownership in the primary and forwards assigned-vector interrupts to the spawned kernel.

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 VF DMA;
• the secondary sees its assigned VF through a synthetic PCI root;
• the PF, physical bridges, and unrelated PCI functions are not enumerated through normal PCI paths;
• normal PCI configuration accesses are serviced by the primary after sender and active-lease validation;
• the primary allocates assigned-device MSI/MSI-X vectors and forwards their interrupts to the secondary;
• 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,
host-side isolated-MSI capability, Function Level Reset support, and a DMA
aperture capable of covering every instance memory region. Instance memory
cannot be changed while an IOMMU-backed VF lease is active.

The spawned kernel remains a privileged, cooperative kernel. The host-mediated
PCI configuration path prevents accidental access through normal in-kernel
paths; it is not a security boundary against a spawned kernel deliberately
accessing physical configuration mechanisms. The host-owned IOMMU domain is the
hardware boundary for device DMA.

Intel VT-d blocks and logs out-of-domain DMA faults through its normal fault
path, but this series does not claim portable automatic instance failure on
IOMMU faults.

This work can be demonstrated using the sriov-vf-assignment branch here:
https://github.com/nickolaev/multikernel/tree/sriov-vf-assignment

The QEMU harness verifies host-mediated PCI configuration and MSI-X delivery,
VF enumeration and traffic in the spawned kernel, continued PF operation in the
primary, IOMMU-domain setup, exclusive ownership, adverse lifecycle operations,
same-instance restart with VF reset, repeated create/delete cycles, driver
restoration, and unexpected VF loss handling.

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.

[congwang-mk]

@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.

Thank you for doing it. I will take a look during the weekend, since I am still working on the refactoring to prepare for ARM/RISCV (which is also why you got merge conflicts).

[congwang-mk]

Thanks for the update! The layering is a clear improvement: synthetic roots instead of physical bridges, manifest-owned BAR/identity metadata, pci_set_dev_assigned() for the SR-IOV interlock, and prepare/commit/rollback. Main things I think need an answer before this lands:

1. Interrupts are not in the ownership model. The spawn kernel calls disable_acpi(), so no DMAR, no IR, no IO-APIC: it composes compatibility-format MSIs. But mk_pci_iommu_validate_group() requires iommu_group_has_isolated_msi(), i.e. host IR is on, and Linux blocks compat-format interrupts in that case. Nothing allocates an IRTE for the VF. Who owns interrupt remapping for an assigned VF?

2. Fail-closed on IOMMU faults does not work on Intel. report_iommu_fault() is only called by amd/arm-smmu and the embedded drivers; VT-d faults go through dmar_fault(), which just logs. mk_pci_iommu_fault() is dead code on the platform you tested.

3. Teardown deadlock. mk_pci_release_assignment() calls cancel_work_sync(&failure_work) on a path holding mk_instance_mutex (via mk_instance_destroy()), while the work reaches mk_instance_find() through mk_send_message() and takes that same mutex.

4. No VF reset across instance restart. Quiesce runs only at lease release, so a force-halted and restarted instance gets a VF with bus mastering possibly still on and DMA in flight into memory the new boot reuses.

5. The early fixup fires on the host. mk_pci_restore_resources() is PCI_ANY_ID and gated only on root_instance->dtb_data, which baseline sets on the host too. resources_valid is set at commit and never cleared on release, so after one assign/release cycle a host rescan of that VF gets non_compliant_bars = true and stale BARs.

6. Filter is one layer too high. raw_pci_ops/raw_pci_ext_ops are left unfiltered and only pci_root_ops is wrapped. On x86 everything funnels through raw_pci_read(), so filtering there would cover both and make "before hardware access" accurate.

7. Framing. An instance is a full kernel with its own CR3: it can map ECAM directly (bus-granular, so it covers sibling VFs including other instances'), use CF8/CFC, or map any physical page. The config filter prevents accidents, not attacks. The IOMMU domain is the one real boundary, and it constrains the device rather than the instance. Worth saying so explicitly.

[congwang-mk]

Separate from the item list above, a thought about the shape rather than the bugs.

SR-IOV VFs are built assuming something mediates. VF config space is impoverished by design because a hypervisor is expected to synthesize the missing parts from the PF's SR-IOV capability. Multikernel's premise is that there is no mediator, so the series meets a mediator-shaped hole and fills it two ways: the manifest for BARs and identity, which works because those are static, and a config-op filter for everything else, which does not, because the filter lives inside the kernel it is meant to constrain. The interrupt gap is the same mismatch surfacing where it cannot be papered over.

But multikernel already has the right mechanism: a host that owns global state and a message ring to reach it. That suggests splitting along the axis that actually exists:

• Static facts (BAR resources, identity, ECAM geometry): manifest, as you already do. This is the strongest part of the series.
• Shared control planes (config space, MSI vector allocation and IRTE programming): host-mediated over the message ring. Config access is not a fast path, and mediating it makes the filter enforceable rather than advisory. For MSI, the host allocates vectors targeting instance CPUs, programs the IRTEs, and returns address/data; the instance's MSI domain becomes a thin client. That is what a VMM does for a guest, expressed as a host-kernel service instead of emulation.

Keep the synthetic roots and the IOMMU domain either way. The identity-mapped domain in particular fits well: with no second-level translation it range-restricts a device rather than virtualizing an address space, which is simpler than what VFIO needs.

The obvious cost is latency on mediated config access, and I have not measured what that does to something like igbvf at probe time. Worth a quick experiment before committing.

[nickolaev]

Separate from the item list above, a thought about the shape rather than the bugs.

SR-IOV VFs are built assuming something mediates. VF config space is impoverished by design because a hypervisor is expected to synthesize the missing parts from the PF's SR-IOV capability. Multikernel's premise is that there is no mediator, so the series meets a mediator-shaped hole and fills it two ways: the manifest for BARs and identity, which works because those are static, and a config-op filter for everything else, which does not, because the filter lives inside the kernel it is meant to constrain. The interrupt gap is the same mismatch surfacing where it cannot be papered over.

But multikernel already has the right mechanism: a host that owns global state and a message ring to reach it. That suggests splitting along the axis that actually exists:

• Static facts (BAR resources, identity, ECAM geometry): manifest, as you already do. This is the strongest part of the series.
• Shared control planes (config space, MSI vector allocation and IRTE programming): host-mediated over the message ring. Config access is not a fast path, and mediating it makes the filter enforceable rather than advisory. For MSI, the host allocates vectors targeting instance CPUs, programs the IRTEs, and returns address/data; the instance's MSI domain becomes a thin client. That is what a VMM does for a guest, expressed as a host-kernel service instead of emulation.

Keep the synthetic roots and the IOMMU domain either way. The identity-mapped domain in particular fits well: with no second-level translation it range-restricts a device rather than virtualizing an address space, which is simpler than what VFIO needs.

The obvious cost is latency on mediated config access, and I have not measured what that does to something like igbvf at probe time. Worth a quick experiment before committing.

Thanks for the review @congwang-mk
I have updated the branch to handle all the point except the interrupt ownership and the proposed host-mediated PCI configuration. Let me run sme more tests and see if these can fit on top of this branch or we want a follow-up.

[nickolaev]

OK, so the host-mediated PCI config is now in place and IRQ ownership is resolved.

[congwang-mk]

Code review of the SR-IOV VF assignment series. 8 findings inline: 3 that look like real breakage (link failure, atomic-context deadlock, use-after-free), 4 medium, 1 cleanup.

[congwang-mk]

Link failure when CONFIG_PCI_MMCONFIG=n. The five mk_pci_msi_* functions (230, 238, 271, 285, 306) are inside the #ifdef CONFIG_PCI_MMCONFIG block; the #else arm only re-provides mk_arch_snapshot_pci_host_bridges and the x86_init.pci hooks. multikernel.h declares them unconditionally under MULTIKERNEL && X86 && PCI, and drivers/pci/msi/msi.c:244 + irqdomain.c:15,19,31,34,42 call them unconditionally.

PCI_MMCONFIG depends on ACPI || JAILHOUSE_GUEST, so a spawn kernel with CONFIG_ACPI=n (what this series targets) fails to link vmlinux with five undefined references.

[congwang-mk]

Synchronous RPC re-dispatches the whole IPI ring from atomic context. mk_pci_remote_config() and mk_pci_send_irq_request() (:214) busy-wait up to 1s in mk_poll_ipi_messages(), which drains the ring and runs every handler, including mk_pci_irq_forward_handler() -> generic_handle_irq_safe() -> the assigned device's ISR.

Both callers run IRQs-off under a raw spinlock: config accesses come via pci_bus_read/write_config_* holding pci_lock; mk_pci_msi_bind() is reached from __pci_write_msi_msg() under desc->lock with IRQs off during irq_startup().

Deadlock: driver probe does pci_read_config_word(), the poll dispatches a forwarded MSI, that ISR issues a config read -> self-deadlock on the non-recursive pci_lock, same CPU. Even without re-entry, spinning 1s IRQs-off trips the hard-lockup watchdog.

[congwang-mk]

Instance freed after failed resource release -> use-after-free. This only WARN_ON_ONCE()s the error, then kfree(instance) two lines down.

On failure mk_pci_release_assignments() (kernel/multikernel/pci.c:1697-1717) breaks out of its loop, leaving the mk_pci_assignment linked on both instance->pci_assignments (now freed) and the global active list, with assignment->instance dangling. A VF whose FLR times out during teardown gets there; the next BUS_NOTIFY_UNBOUND_DRIVER runs mk_pci_assignment_failure_work(), which dereferences assignment->instance->state and ->name.

mk_instance_destroy() and mk_create_instance_from_dtb() do honor this error; the kref path is the outlier.

[congwang-mk]

Ring consumption is no longer FIFO. The new drain scans all MK_IPI_RING_SIZE slots from tail and consumes anything READY, skipping WRITING. Slot order no longer equals delivery order: A claims slot 5, B claims 6, B publishes first -> 6 is delivered before 5.

mk_vsock_ipi_handler() turns each payload into an skb on a byte-stream socket, so two concurrent senders now corrupt the stream rather than just delaying it. The goal here (an interrupted producer must not block others) is reachable without breaking ordering in the common case.

[congwang-mk]

MSI bind failure is swallowed, leaving a silently dead vector. mk_pci_msi_write_msg() (arch/x86/multikernel/pci.c:271) logs the mk_pci_msi_bind() error with pr_err_ratelimited() and then returns true unconditionally, so __pci_write_msi_msg() stores entry->msg and returns as if programmed.

On RPC timeout or -ESTALE/-ENODEV, pci_alloc_irq_vectors() and request_irq() both succeed while the host never enabled the corresponding vector. The VF driver then waits forever for an interrupt that never arrives, with no error visible to it.

[congwang-mk]

CPU-ownership mutex held across sleeping MSI work. This holds mk_cpu_ownership_lock() across mk_pci_irq_access(), which can msleep(MK_PCI_FLR_SETTLE_MS + 1), pci_alloc_irq_vectors(), request_irq() and free_irq() (synchronize_irq). mk_pci_cfg_work_fn() (:505) does the same.

Every mk_instance_transfer_cpus() / mk_send_cpu_add() / mk_send_cpu_remove() on any instance stalls behind an unrelated instance's MSI setup, and the requester's own 1s deadline can expire while the host is still in the FLR sleep -> spurious -ETIMEDOUT. Only the mk_pci_request_route_stale check actually needs the ownership lock.

[congwang-mk]

Forwarded MSI silently dropped on allocation/backpressure failure. This hardirq handler forwards via mk_send_message_to_instance() -> __mk_send_message(), which does a kzalloc(GFP_ATOMIC) per interrupt and returns -ENOSPC from mk_ipi_ring_claim_slot() when the 64-slot ring is full. The handler only pr_warn_ratelimited()s and returns IRQ_HANDLED.

Edge-triggered MSI never re-asserts, so under memory pressure or ring backpressure the spawn kernel permanently loses that completion (e.g. an igbvf TX/RX cleanup interrupt) and the queue hangs. No retry, coalescing, or pending-interrupt fallback.

[congwang-mk]

Dead stores; the "saved backend" does not exist. raw_pci_ops/raw_pci_ext_ops are set to &pci_mmcfg and immediately overwritten by the filtered ops, and nothing captures pci_mmcfg anywhere.

The commit message says accepted accesses are "forwarded to the saved backend", but mk_pci_raw_read/write always go out as a host RPC. The ECAM windows registered by pci_mmconfig_add() and mapped by pci_mmcfg_arch_init() just above are therefore mapped and never used. Either wire the local backend up or drop the ECAM mapping and these two stores, since as written it reads like there is a local fast path.

[congwang-mk]

I am wondering why you have to handle clock in this PR? If anything is wrong with clock, please separate it out