firmware_uefi: EfiDiagnostics should flush when unprocessed after reset or shutdown

[maheeraeron]

This PR addresses a gap where a user could face a VM shutdown or reset on failure that goes beyond the UEFI crash path before ExitBootServices. In this case, so long as we have a GPA, we will forcibly flush the UEFI logs on reset or shutdown if they haven't been processed before

[Copilot]

Pull request overview

This PR ensures UEFI diagnostics are not silently lost when a guest resets or stops without going through the normal diagnostics/ExitBootServices path by proactively flushing pending diagnostics if a diagnostics buffer GPA is present and has not yet been processed.

Changes:

• Added a helper (has_unprocessed_diagnostics) to detect when diagnostics are pending and a GPA is available.
• Triggered diagnostics processing during UefiDevice::stop() and UefiDevice::reset() when pending diagnostics exist.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
vm/devices/firmware/firmware_uefi/src/service/diagnostics/mod.rs	Adds a predicate to detect pending/unprocessed diagnostics with a valid GPA.
vm/devices/firmware/firmware_uefi/src/lib.rs	Flushes diagnostics on device stop/reset when they haven’t been processed yet.

Comments suppressed due to low confidence (1)

vm/devices/firmware/firmware_uefi/src/lib.rs:360

• This stop/reset flush path uses WATCHDOG_LOGS_PER_PERIOD, but the constant name/doc in service::diagnostics indicates it is specifically for watchdog timeouts. Using a watchdog-specific limit here is confusing and makes it easy to change the watchdog limit accidentally impacting stop/reset behavior; consider using DEFAULT_LOGS_PER_PERIOD or introducing a dedicated constant for the stop/reset flush case.

            let _ = self.process_diagnostics(
                false,
                service::diagnostics::DiagnosticsEmitter::Tracing {
                    limit: Some(WATCHDOG_LOGS_PER_PERIOD),
                },
                Some(LogLevel::make_info()),
            );

[maheeraeron]

Now the real question is, how can I reliably test this? There was an incident with Databricks who had a custom bootloader that unknowingly fails and resets the guest, dodging the UEFI crash path and exit boot services.

Can we test a private winload that reproduces this? Simply turning off the VM in hyper-v won't work, that tears down everything so we never get to this point

[Copilot]

Pull request overview

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

[github-actions]

1 Petri tests failed (1 unstable)