On 06/25/15 15:10, Ard Biesheuvel wrote: > On 25 June 2015 at 14:16, Laszlo Ersek <ler...@redhat.com> wrote:
>> Looks good, but you're going to hate me nonetheless. Because, our >> exchange has been too quick, and my thoughts about addressing the same >> in OvmfPkg had not matured enough until I posted my v1 review. >> >> Namely, both OvmfPkg and ArmPlatformPkg contain the following snippet at >> the very end of their respective PlatformBdsPolicyBehavior() functions: >> >> BdsLibEnumerateAllBootOption (BootOptionList); >> >> SetBootOrderFromQemu (BootOptionList); >> // >> // The BootOrder variable may have changed, reload the in-memory list with >> // it. >> // >> BdsLibBuildOptionFromVar (BootOptionList, L"BootOrder"); >> >> PlatformBdsEnterFrontPage (GetFrontPageTimeoutFromQemu(), TRUE); >> >> The pair (BdsLibEnumerateAllBootOption(), SetBootOrderFromQemu()) >> massages UEFI non-volatile variables (boot options) quite heavily. The >> first creates a bunch of new boot options, while the second prunes quite >> a few of those. (This is necessary because a VM's hardware might change >> dynamically before every single boot, so everything needs to be >> enumerated, and then filtered / reordered according to the fw_cfg boot >> order file, every time.) >> >> Since one of your stated goals is "variable reclaim" before booting the >> OS, I propose (for both ArmVirtPkg and my future OvmfPkg patch(es)) that >> we signal the event right before the PlatformBdsEnterFrontPage() call -- >> ie. as the penultimate step of PlatformBdsPolicyBehavior() --, rather >> than in PlatformBdsInit(). Then the reclaim would cover the variable >> churn incurred by those two functions I named above. >> >> What do you think? >> > > The PI spec says > > """ > 5.1.2.1 End of DXE Event > Prior to invoking any UEFI drivers, applications, or connecting > consoles, the platform should signal > the event EFI_END_OF_DXE_EVENT_GUID. > """ > > so I don't think that is going to fly. If the variable churn is a > concern, perhaps it is better to trigger another reclaim round in some > way? The variable churn is not a "concern", just an idea for covering as much ground with the reclaim as possible. But, you are right, I forgot about the PI requirement. So I believe your v2 is fine; it certainly doesn't miss out on any reclaim possibilities that the pre-patch code already exploits. Reviewed-by: Laszlo Ersek <ler...@redhat.com> I'll have to see how the ordering requirements can be reconciled in OVMF's PlatformBdsLib. Thanks Laszlo ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
