On 25 June 2015 at 16:33, Laszlo Ersek <ler...@redhat.com> wrote: > 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> >
Thanks. I will go ahead and apply it. -- Ard. ------------------------------------------------------------------------------ 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
