feat(krun): make virtio-vsock opt-in when TSI does not need it#47
Merged
Conversation
Previously Vm::build() unconditionally attached a virtio-vsock device via configure_vsock(). That consumed a permanent IRQ + MMIO slot even for VMs that never use vsock — typically ones with virtio-net and more than one virtio-fs tag, where neither HIJACK_INET nor HIJACK_UNIX applies and the vsock has no actual work to do. Skip the attach in that case and let callers opt in when they need guest-visible vsock sockets for their own purposes. - src/krun/src/api/vm.rs: configure_vsock() now early-returns when the caller hasn't opted in (VmResources::request_vsock) and no TSI flag is needed. builder.rs (VMM side) already only injects tsi_hijack / tsi_hijack_unix into the kernel cmdline inside `if let Some(vsock) = vm_resources.vsock.get()`, so the guest never gets told to expect a transport that isn't there. - src/krun/src/api/builders.rs + builder.rs: add MachineBuilder::vsock(bool), threaded through to vmr.request_vsock. - src/vmm/src/resources.rs: add request_vsock: bool (default false) alongside the existing split_irqchip flag. Guest is safe with the device absent: the krun-init shipped in libkrunfw is built without __TIMESYNC__, so it has no AF_VSOCK callers; and Linux's CONFIG_VIRTIO_VSOCKETS driver sits dormant when no virtio-vsock device is enumerated. Even with TIMESYNC enabled, socket(AF_VSOCK, ...) returning ENODEV is handled gracefully in clock_worker(). Net effect for microsandbox's typical VM: baseline virtio-mmio IRQ use drops by one (from 8 to 7 on x86_64), freeing an extra slot for user-defined mounts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Vm::build().configure_vsocknow only attaches it when the TSI transport needs it (no virtio-net in guest →HIJACK_INET, or single root virtio-fs on Linux →HIJACK_UNIX) or when the caller explicitly opts in.MachineBuilder::vsock(bool)for callers that want a guest-visible vsock device even when TSI wouldn't otherwise require one, backed by a newVmResources::request_vsockflag.krun-initshipped in libkrunfw is built without__TIMESYNC__and therefore has noAF_VSOCKcallers; Linux's built-inCONFIG_VIRTIO_VSOCKETSdriver sits dormant when no matching device is enumerated. The VMM-sidetsi_hijack*kernel-cmdline injection inbuilder.rsalready lives insideif let Some(vsock) = vm_resources.vsock.get(), so the guest is never told to expect a transport that isn't there.Test Plan
cargo build -p msb_krun— cleancargo fmt --checkjust build && just install,msb run alpineboots and exits cleanlytsi_hijackshould appear in the guest kernel cmdline.vsock(true)forces the device on even when both TSI flags would be empty (virtio-net configured plus multiple fs tags)