Add support for running UEFI without VMBus#76
Conversation
Some VM configurations do not require VMBus, but the UEFI firmware currently assumes it is always present. This causes issues when the host does not provide MMIO gap configuration, and leaves unnecessary VMBus devices in the ACPI namespace. Introduce a VmbusDisabled flag in the UEFI_CONFIG_FLAGS blob that the host can set to indicate VMBus is not available. The flag uses disabled polarity so that the default zero value in reserved bits preserves existing behavior. This is exposed as PcdVmbusEnabled internally, which gates VMBus driver initialization, DSDT VMBus device presence, and MMIO gap HOB publication. The MMIO ranges blob is no longer required when VMBus is disabled, since those ranges are only used for VMBus device assignment. On AARCH64, the MMU setup falls back to a flat memory map when no MMIO gap information is provided, since the existing code assumes MMIO ranges are always available to carve out of the address space. Hyper-V enlightenments (hypercalls, synthetic timers) remain functional regardless of VMBus state, as they operate independently via the hypervisor interface. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| gInternalEventServicesProtocolGuid ## CONSUMES | ||
|
|
||
| [Pcd] | ||
| gMsvmPkgTokenSpaceGuid.PcdVmbusEnabled ## CONSUMES |
| PADE,8, // Processor Aggregator Device enabled/disabled | ||
| CCFG,8, // CXL memory support enabled/disabled | ||
| NCNT,16, // NVDIMM count | ||
| VCFG,8, // VMBus enabled/disabled |
There was a problem hiding this comment.
trying to remember if alignment matters here
mebersol
left a comment
mebersol
left a comment
There was a problem hiding this comment.
[Copilot] Looks good overall — clean gating across PEI/DXE/ACPI. Left a few minor suggestions inline.
| @@ -941,6 +942,7 @@ ConfigSetUefiConfigFlags( | |||
| PEI_FAIL_FAST_IF_FAILED(PcdSetBoolS(PcdWatchdogEnabled, (UINT8) ConfigFlags->Flags.WatchdogEnabled)); | |||
| PEI_FAIL_FAST_IF_FAILED(PcdSetBoolS(PcdTpmLocalityRegsEnabled, (UINT8) ConfigFlags->Flags.TpmLocalityRegsEnabled)); | |||
| PEI_FAIL_FAST_IF_FAILED(PcdSetBoolS(PcdMtrrsInitializedAtLoad, (UINT8) ConfigFlags->Flags.MtrrsInitializedAtLoad)); | |||
There was a problem hiding this comment.
[Copilot] nit: !ConfigFlags->Flags.VmbusDisabled is equivalent and shorter, but the ternary does make the polarity inversion explicit. Either way is fine — just flagging the option. #Closed
| // | ||
| // If VMBus is disabled, MMIO ranges are not required since they are | ||
| // VMBus MMIO gaps. | ||
| // | ||
| if (!PcdGetBool(PcdVmbusEnabled)) | ||
| { | ||
| requiredStructures.UefiConfigMmioRanges = 1; | ||
| } |
There was a problem hiding this comment.
[Copilot] The "pretend it was found" pattern (requiredStructures.UefiConfigMmioRanges = 1) is a bit subtle. Consider adding a comment here linking the concepts — something like:\n\nc\n// MMIO ranges describe VMBus MMIO gaps and are only required when VMBus is enabled.\n// Mark the structure as found so the validation below does not fail.\n\n\nThe field name UefiConfigMmioRanges doesn't obviously connect to VMBus for a future reader.
| // as DEVICE in stage-1. | ||
| // | ||
| if (!PcdGetBool(PcdVmbusEnabled)) | ||
| { |
There was a problem hiding this comment.
[Copilot] If MaxAddress is ever UINT64_MAX, this wraps to 0 and produces a zero-length region. In practice the AARCH64 physical address space is ≤52 bits so this shouldn't happen, but an ASSERT(MaxAddress < MAX_UINT64) or a comment noting the assumption would be cheap insurance.
3 participants
Some VM configurations do not require VMBus, but the UEFI firmware currently assumes it is always present. This causes issues when the host does not provide MMIO gap configuration, and leaves unnecessary VMBus devices in the ACPI namespace.
Introduce a VmbusDisabled flag in the UEFI_CONFIG_FLAGS blob that the host can set to indicate VMBus is not available. The flag uses disabled polarity so that the default zero value in reserved bits preserves existing behavior. This is exposed as PcdVmbusEnabled internally, which gates VMBus driver initialization, DSDT VMBus device presence, and MMIO gap HOB publication. The MMIO ranges blob is no longer required when VMBus is disabled, since those ranges are only used for VMBus device assignment.
On AARCH64, the MMU setup falls back to a flat memory map when no MMIO gap information is provided, since the existing code assumes MMIO ranges are always available to carve out of the address space.
Hyper-V enlightenments (hypercalls, synthetic timers) remain functional regardless of VMBus state, as they operate independently via the hypervisor interface.