Add config blob RAM disk registration for direct kernel boot#79
Draft
jstarks wants to merge 1 commit into
Draft
Conversation
Add a mechanism for the host to declare RAM disk(s) in the config blob, which the firmware registers via EFI_RAM_DISK_PROTOCOL during DXE. This makes them available as SimpleFileSystem volumes that BDS can boot from via standard Boot####/BootOrder variables (which the host also controls via NVRAM). The implementation consists of: - A new config blob structure type (UefiConfigRamDisk = 0x29) containing the GPA and size of a RAM disk image. Multiple instances are supported. - PEI parsing in Config.c that validates each entry, marks the memory as allocated boot services data (so DXE won't use it), and creates a GUIDed HOB for DXE to consume. - A new DXE driver (RamDiskConfigDxe) that enumerates the HOBs and calls EFI_RAM_DISK_PROTOCOL.Register() for each entry. The existing driver stack (DiskIoDxe, PartitionDxe, Fat.inf) then exposes the volumes. The driver is intentionally minimal -- all boot policy is handled by the host via NVRAM Boot#### variables. The firmware just makes the volumes available.
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adds support for registering RAM disks declared in the IGVM/UEFI configuration blob. PlatformPei parses a new UefiConfigRamDisk structure, reserves the memory, and builds a GUIDed HOB; a new DXE driver (RamDiskConfigDxe) consumes those HOBs and registers each RAM disk via EFI_RAM_DISK_PROTOCOL.
Changes:
- Define new
UefiConfigRamDiskconfig type and a shared HOB header. - Parse RAM disk entries in PlatformPei and publish HOBs.
- Add
RamDiskConfigDxedriver and wire it into X64/AARCH64 DSC/FDF.
Reviewed changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| MsvmPkg/Include/BiosInterface.h | Adds UefiConfigRamDisk enum and UEFI_CONFIG_RAM_DISK struct. |
| MsvmPkg/Include/RamDiskConfigHob.h | New header defining HOB GUID and payload struct. |
| MsvmPkg/MsvmPkg.dec | Registers the new HOB GUID. |
| MsvmPkg/PlatformPei/Config.c | Parses RAM disk config, reserves memory, builds HOB. |
| MsvmPkg/PlatformPei/PlatformPei.inf | Declares the new HOB GUID dependency. |
| MsvmPkg/RamDiskConfigDxe/RamDiskConfigDxe.c | New DXE driver registering RAM disks via protocol. |
| MsvmPkg/RamDiskConfigDxe/RamDiskConfigDxe.inf | INF for the new DXE driver. |
| MsvmPkg/MsvmPkgX64.dsc / .fdf | Adds the new driver for X64. |
| MsvmPkg/MsvmPkgAARCH64.dsc / .fdf | Adds the new driver for AARCH64. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| gEfiRamDiskProtocolGuid | ||
|
|
||
| [Depex] | ||
| gEfiRamDiskProtocolGuid |
Comment on lines
+68
to
+70
| EFI_HOB_GUID_TYPE *GuidHob = (EFI_HOB_GUID_TYPE *)Hob; | ||
| RAM_DISK_CONFIG_HOB_DATA *Data = (RAM_DISK_CONFIG_HOB_DATA *)GET_GUID_HOB_DATA (GuidHob); | ||
| EFI_DEVICE_PATH_PROTOCOL *DevicePath = NULL; |
Comment on lines
+72
to
+73
| DEBUG ((DEBUG_INFO, "RamDiskConfigDxe: Registering RAM disk #%u at GPA 0x%lx, Size 0x%lx\n", | ||
| Count, Data->RamDiskGpa, Data->RamDiskSize)); |
Comment on lines
+1661
to
+1665
| if (ramDisk->RamDiskGpa == 0 || ramDisk->RamDiskSize == 0) | ||
| { | ||
| DEBUG((DEBUG_ERROR, "*** RamDisk: GPA or Size is zero\n")); | ||
| FAIL_FAST_UNEXPECTED_HOST_BEHAVIOR(); | ||
| } |
Comment on lines
+20
to
+22
| #define MSVM_RAM_DISK_CONFIG_HOB_GUID \ | ||
| { 0xa41d6c49, 0xaf34, 0x4e34, { 0xa0, 0xb3, 0x12, 0x9a, 0x48, 0x66, 0x70, 0xcd } } | ||
|
|
Comment on lines
+68
to
+71
| EFI_HOB_GUID_TYPE *GuidHob = (EFI_HOB_GUID_TYPE *)Hob; | ||
| RAM_DISK_CONFIG_HOB_DATA *Data = (RAM_DISK_CONFIG_HOB_DATA *)GET_GUID_HOB_DATA (GuidHob); | ||
| EFI_DEVICE_PATH_PROTOCOL *DevicePath = NULL; | ||
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a mechanism for the host to declare RAM disk(s) in the config blob, which the firmware registers via EFI_RAM_DISK_PROTOCOL during DXE. This makes them available as SimpleFileSystem volumes that BDS can boot from via standard Boot####/BootOrder variables (which the host also controls via NVRAM).
The implementation consists of:
A new config blob structure type (UefiConfigRamDisk = 0x29) containing the GPA and size of a RAM disk image. Multiple instances are supported.
PEI parsing in Config.c that validates each entry, marks the memory as allocated boot services data (so DXE won't use it), and creates a GUIDed HOB for DXE to consume.
A new DXE driver (RamDiskConfigDxe) that enumerates the HOBs and calls EFI_RAM_DISK_PROTOCOL.Register() for each entry. The existing driver stack (DiskIoDxe, PartitionDxe, Fat.inf) then exposes the volumes.
The driver is intentionally minimal -- all boot policy is handled by the host via NVRAM Boot#### variables. The firmware just makes the volumes available.