openvmm: support UEFI boot over ttrpc

[jstarks]

CreateVM rejected any UEFI boot configuration outright, so the ttrpc interface could only start Linux direct-boot VMs. Wire up UEFI: the boot configuration now selects the base chipset alongside the load mode, since the firmware and device model must agree on the platform, and a UEFI boot attaches the helper device that provides the variable store and runtime services. Serial setup moves ahead of boot configuration so the firmware console can be enabled only when a port is configured and routed to COM1 when available; otherwise firmware in a VM without a graphics adapter has nowhere to write.

Extend the UEFI configuration with initial variables that are applied only when the variable store is empty. Callers can select the Microsoft Windows or Microsoft UEFI CA Secure Boot variable template independently from the Secure Boot policy boolean, so key enrollment and signature enforcement remain separate choices. The store remains ephemeral for now. The proto also removes device_path and optional_data, which had no OpenVMM equivalent and were never honored, while reserving their field numbers and names.

Add a guest reset action so callers can choose whether a guest reset automatically restarts the VM or leaves it halted. This is needed to observe completion consistently across architectures because the UEFI test image ends with a triple fault on x64 and a reset on aarch64.

Add a test that boots the guest_test_uefi image from a VMBus SCSI disk, initializes the Windows Secure Boot variables while leaving enforcement disabled, and waits for its banner on COM1. Seeing the banner proves the firmware started, enumerated the disk, and launched the application; observing the architecture-specific halt then proves the application completed. The test also covers clean teardown of a VM with a SCSI controller.

[Copilot]

Pull request overview

This PR enables UEFI boot via the OpenVMM ttrpc VM service, expanding the interface beyond Linux direct-boot by selecting a UEFI-compatible base chipset, attaching the required UEFI helper device (NVRAM/runtime services), and configuring serial early enough for firmware console routing. It also trims unsupported UEFI proto fields and adds an end-to-end ttrpc test that boots a UEFI guest from a VMBus SCSI disk and validates output on COM1.

Changes:

• Implement UEFI boot handling in the ttrpc CreateVm path, including base chipset selection and UEFI helper device attachment with an ephemeral variable store.
• Update the vmservice proto to remove unused UEFI fields while reserving their field numbers/names for compatibility.
• Add a vmm_tests ttrpc UEFI boot test that confirms firmware + disk enumeration + EFI app launch via a serial banner and waits for guest halt.

Reviewed changes

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

File	Description
vmm_tests/vmm_tests/tests/tests/ttrpc.rs	Adds a ttrpc UEFI boot integration test plus a serial-draining helper that waits for the EFI banner on COM1.
openvmm/openvmm_ttrpc_vmservice/src/vmservice.proto	Removes unused UEFI fields (device_path, optional_data) and reserves their numbers/names for wire compatibility.
openvmm/openvmm_entry/src/ttrpc/mod.rs	Implements UEFI boot support in ttrpc CreateVm, including serial-first setup, chipset selection, and UEFI helper/NVRAM backing.

[github-actions]

3 Petri tests failed (2 unstable)

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

openvmm/openvmm_entry/src/ttrpc/mod.rs:713

• UEFI console routing currently only checks whether COM1 is configured. If a caller configures only COM2 (or wants firmware output on COM2) and the VM has no graphics adapter, leaving uefi_console_mode as default will route output to video and the firmware/app will have nowhere to write. Track whether COM2 is configured so the UEFI boot path can route the console to COM2 when COM1 is unavailable.

        let any_serial_configured = ports.iter().any(|port| port.is_some());
        let com1_configured = ports[0].is_some();

openvmm/openvmm_entry/src/ttrpc/mod.rs:790

• When COM1 is not configured, this leaves uefi_console_mode unset (defaulting to video), which can drop all firmware output on headless VMs even if COM2 is configured. Prefer routing the UEFI console to COM1 when available, otherwise COM2 when available.

                        // Route the firmware console to COM1 when it is
                        // available. The firmware's default console is the
                        // video device, so without this the firmware and
                        // anything it launches would have nowhere to write on a
                        // VM with no graphics adapter.
                        uefi_console_mode: com1_configured.then_some(UefiConsoleMode::Com1),
                        bios_guid: Guid::new_random(),

[github-actions]

2 Petri tests failed (0 unstable)

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

openvmm/openvmm_entry/src/ttrpc/mod.rs:790

• uefi_console_mode is only routed to COM1. If a caller configures only COM2 (or higher), enable_serial becomes true but the firmware console still defaults to video, leaving headless UEFI VMs with no usable console output despite a configured serial port. Consider routing to the first configured serial port (e.g., COM1 preferred, then COM2).

                        // Route the firmware console to COM1 when it is
                        // available. The firmware's default console is the
                        // video device, so without this the firmware and
                        // anything it launches would have nowhere to write on a
                        // VM with no graphics adapter.
                        uefi_console_mode: com1_configured.then_some(UefiConsoleMode::Com1),
                        bios_guid: Guid::new_random(),

[github-actions]

2 Petri tests failed (0 unstable)