> I've talked with our firmware expert today and I think we have a problem > with the approach when kernel declaries support of unaccepted memory. > Is this Jiewen Yao? I've been trying to design the UEFI spec change with him. The bootloader problem he commented with this morning was something I wasn't fully considering. > This apporach doesn't work if we include bootloader into the picture: if > EBS() called by bootloader we still cannot know if target kernel supports > unaccepted memory and we return to the square 1. > > I think we should make it obvious from a kernel image if it supports > unaccepted memory (with UTS_VERSION or other way). > > Any comments? Is this binary parsing trick already used in EDK2? If not, I wouldn't want to introduce an ABI-solidifying requirement like that. A bit more cumbersome, but more flexible way to enable the feature is an idea I had in a meeting today: Make unaccepted memory support a feature-enabling EFI driver installed to the EFI system partition. * The first time you boot (setup mode), you install an EFI driver that just sets a feature Pcd to true (using a custom protocol as Ard had suggested above). * The second time you boot, if the feature Pcd is true, then the UEFI is free to not accept memory and use the unaccepted memory type. The bootloader will run after unaccepted memory has been allowed already, so there is no accept-all event. The default behavior will be to accept all memory when GetMemoryMap is called unless the feature pcd is set to true. We can then say this driver isn't needed once some new generation of this technology comes along and we can require unaccepted memory support as part of that technology's baseline, or we manage to update the UEFI spec to have GetMemoryMapEx which has unaccepted memory support baked in and the bootloaders all know to use it. The cloud experience will be, "is boot slow? Install this EFI driver from the cloud service provider" to tell the UEFI to enable unaccepted memory. -- -Dionna Glaze, PhD (she/her)
