Crate firmware_uefi

source ·
Expand description

UEFI helper device.

A bespoke virtual device that works in-tandem with the custom Hyper-V UEFI firmware running within the guest.

This device is primarily concerned with implementing + exposing the various runtime services the UEFI code interfaces with.

NOTE: Unlike Hyper-V’s implementation, this device is not responsible for injecting UEFI config blobs into guest memory (i.e: things like VM topology information, device enablement info, etc…). That happens outside this device, as part of VM initialization, in tandem with loading the UEFI image itself.

§Crate Structure

The idea behind this organization is that conceptually, the UEFI device isn’t so much a single unified device, rather, it’s a hodge-podge of little “micro-devices” that all happen to be dispatched via a single pair of ports.

§mod service:

The individual UEFI device services themselves.

What is a service? As a rule of thumb: a service is something that has one/more UefiCommands associated with it.

Rather than having each service directly handle its own IO port routing, the top-level UefiDevice code in lib.rs takes care of that in one central location. That way, the only thing service implementations needs to expose is are service-specific “handler” functions.

e.g: there’s no reason for, say, UEFI generation ID services to directly share state with the UEFI watchdog service, or the event log service. As such, each is modeled as a separate struct + impl.

§pub mod platform

A centralized place to expose various service-specific interface traits that must be implemented by the “platform” hosting the UEFI device.

This layer of abstraction allows the re-using the same UEFI emulator between multiple VMMs (HvLite, Underhill, etc…), without tying the emulator to any VMM specific infrastructure (via some kind of compile-time feature flag infrastructure).

Modules§

  • platform
    Platform interfaces required by the UEFI device.
  • service
    Various UEFI device subsystems.

Structs§

Enums§