patina_dxe_core: Add DxeDispatch service for driver dispatch

[kat-perez]

Description

Add a DxeDispatch service trait in the SDK and a CoreDxeDispatch
implementation in patina_dxe_core that delegates to the PI dispatcher.
The service is registered alongside other core services (MemoryManager,
PerfTimer, etc.) and consumed via dependency injection by components
that need to trigger driver dispatch passes.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

• Built SBSA DXE core binary with BootDispatcher + SimpleBootManager consuming the service via DI
• Booted Windows ARM64 under QEMU SBSA-ref with Patina BDS handling the full boot flow
• Connect-dispatch interleaving discovered AHCI device, expanded partial device path, loaded Windows bootloader, ExitBootServices completed
• 106 on-system unit tests passed (0 fails)

Integration Instructions

The DxeDispatch service is registered automatically by the DXE core.
Components consume it via dependency injection:

fn entry_point(self, dxe_dispatch: Service<dyn DxeDispatch>) -> Result<()> {
    dxe_dispatch.dispatch()?;
    Ok(())
}

[patina-automation]

✅ QEMU Validation Passed

All QEMU validation jobs completed successfully.

Note: Q35 is only built on Windows hosts (QEMU boot is disabled due to a QEMU vfat issue).

Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/23361899596

Boot Time to EFI Shell

Platform	Elapsed
Q35 (Linux Host)	29.6s
SBSA (Linux Host)	36.0s

Dependencies

Repository	Ref
patina	6f12730
patina-dxe-core-qemu	20381f1
patina-fw-patcher	3b8900d
patina-qemu firmware	v2.0.0
patina-qemu build script	2e45e9b

This comment was automatically generated by the Patina QEMU PR Validation Post workflow.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
patina_dxe_core/src/dxe_dispatch_service.rs	0.00%	6 Missing ⚠️

📢 Thoughts on this report? Let us know!

[os-d]

I don't think making this public makes sense. @Javagedes do you have thoughts on this? Feels like a different paradigm is needed.

[kat-perez]

I could move this to the SDK instead?

Like this at sdk/patina/src/pi/dxe_services.rs?

/// Interface for dispatching DXE drivers.
///
/// Boot orchestrators use this to interleave controller connection
/// with driver dispatch.
pub trait DxeServices: Send + Sync + 'static {
    /// Run a single dispatch pass. Returns `true` if any drivers were dispatched.
    fn dispatch(&self) -> crate::error::Result<bool>;
}

[Javagedes]

Yeah, I don't think we want to make this public outside of the core. It leaks containment of functionality that the platform's top level main() function should not have access to, which could result in platforms doing bad things.

Based off of the current usage:

impl DxeServices for CoreDxeServices {
    fn dispatch(&self) -> patina::error::Result<bool> {
        CORE.dispatch()
    }
}

// Boot orchestration with connect-dispatch interleaving
add.component(BootDispatcher::new(
  SimpleBootManager::new(
    BootConfig::new(create_boot_path())
      .with_failure_handler(|| log::error!("Boot failed: all boot options exhausted")),
    ),
    CoreDxeServices,
));

I think one of these two options better lean into the patina component model via dependency injection:

1. Create a new service trait defined in the patina crate for either (1) only dispatch or (2) the entire dxe services table, and implemented in the core (Similar to the CoreMemoryManager), then consume it through dependency injection
2. Do the same as 1, but instead do it for configuration table functionality, then you can grab the dxe services configuration table and call dispatch from dxe_services

[kat-perez]

Thanks, I'll go with (1.) by making a new service trait instead. Would be something like CoreDxeDispatch, implemented like CoreMemoryManager

[kat-perez]

The platform binary will never touch dispatch() directly