virtio_vsock: add petri boot tests using virtio vsock

[SvenGroot]

This change adds boot tests for Linux direct (with and without OpenHCL) using virtio vsock for the pipette agent connection instead of VMBus hvsocket. This validates end-to-end functionality for the virtio vsock device.

[Copilot]

Pull request overview

This PR adds Petri-based “boot” integration tests that exercise end-to-end guest↔host communication over virtio-vsock (instead of VMBus hvsocket), and wires Petri/OpenVMM configuration to optionally expose a virtio-vsock device plus the corresponding Unix-socket relay path.

Changes:

• Add a new multiarch boot test that runs with PetriVmBuilder::with_virtio_vsock() for Linux-direct (with and without OpenHCL).
• Add a use_virtio_vsock toggle to PetriVmBuilder/PetriVmProperties and plumb it into OpenVMM Petri config construction (including adding a VirtioVsockHandle on the MMIO bus).
• Adjust OpenVMM Petri startup logic (e.g., save/restore capability gating) for virtio-vsock mode.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
vmm_tests/vmm_tests/tests/tests/multiarch.rs	Adds a new virtio-vsock-based boot test for Linux-direct targets.
petri/src/vm/openvmm/start.rs	Disables save/restore when virtio-vsock is enabled.
petri/src/vm/openvmm/mod.rs	Renames stored vsock TempPath field to reflect it’s not VMBus-specific.
petri/src/vm/openvmm/construct.rs	Implements virtio-vsock device wiring + relay path handling + cmdline blacklist selection.
petri/src/vm/mod.rs	Adds builder/property flag + with_virtio_vsock() API and plumbs it through.

Comments suppressed due to low confidence (1)

petri/src/vm/openvmm/construct.rs:813

• In the OpenHCL Linux-direct path, the UNDERHILL_CMDLINE_APPEND still unconditionally injects initcall_blacklist=virtio_vsock_init into the VTL0 Linux cmdline ({VIRTIO_VSOCK_BLACKLIST}), even when PetriVmBuilder::with_virtio_vsock() is enabled. That will prevent the guest virtio-vsock transport from initializing and seems incompatible with the new boot_virtio_vsock test that includes openvmm_openhcl_linux_direct_x64. Consider making the appended blacklist conditional (use the same vsock_blacklist logic as LinuxDirect, or avoid blacklisting virtio when virtio-vsock is the intended transport).

                        // N.B. VTL2 currently still unconditionally uses vmbus for vsock, so always
                        //      blacklist virtio_vsock_init to prevent conflicts.
                        append_cmdline(
                            &mut cmdline,
                            format!(
                                "UNDERHILL_SERIAL_WAIT_FOR_RTS=1 UNDERHILL_CMDLINE_APPEND=\"rdinit=/bin/sh {VIRTIO_VSOCK_BLACKLIST}\""
                            ),

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

petri/src/vm/openvmm/construct.rs:812

• use_virtio_vsock is supported for Firmware::OpenhclLinuxDirect (the new boot_virtio_vsock test includes it), but the Underhill-provided guest cmdline is still hard-coded to blacklist virtio_vsock_init. That will prevent the guest from registering the virtio-vsock transport, and pipette’s AF_VSOCK connection will likely fail because the VMBus hvsock relay is disabled when use_virtio_vsock is true. Consider selecting the initcall blacklist based on self.use_virtio_vsock here as well (e.g., blacklist hv_sock_init when using virtio-vsock).

                        append_cmdline(
                            &mut cmdline,
                            format!(
                                "UNDERHILL_SERIAL_WAIT_FOR_RTS=1 UNDERHILL_CMDLINE_APPEND=\"rdinit=/bin/sh {VIRTIO_VSOCK_BLACKLIST}\""
                            ),

[Copilot]

Avoid unwrap() when extracting the vsock listener for the virtio-vsock device. Even if the current control flow makes it unlikely to be None, a panic here will abort the whole test run; prefer converting this into an anyhow error with helpful context (or restructure so the listener is moved in a way that cannot fail).

Suggested change

	virtio_devices.push((
	// Use the MMIO bus because PCI is not available on Linux direct boot configurations.
	VirtioBus::Mmio,
	VirtioVsockHandle {
	guest_cid: 0x3,
	base_path: vsock_path_string.to_string(),
	listener: vsock_listener.take().unwrap(),
	let listener = vsock_listener
	.take()
	.ok_or_else(|| anyhow::anyhow!("virtio vsock enabled but vsock_listener is missing"))?;
	virtio_devices.push((
	// Use the MMIO bus because PCI is not available on Linux direct boot configurations.
	VirtioBus::Mmio,
	VirtioVsockHandle {
	guest_cid: 0x3,
	base_path: vsock_path_string.to_string(),
	listener,