On 05/11/16 06:53, Gary Lin wrote: > On Tue, May 10, 2016 at 05:29:33PM +0200, Laszlo Ersek wrote: >> On 05/10/16 06:34, Gary Lin wrote: >>> On Mon, May 09, 2016 at 02:58:00PM +0200, Laszlo Ersek wrote: >>>> On 05/09/16 13:39, Thomas Lamprecht wrote: > [snip] >>> Speaking of the boot order, I would like to propose to postpone the >>> registration of the internal shell after >>> EfiBootManagerRefreshAllBootOption() >>> in PlatformBootManagerAfterConsole(). The reason is to align to the >>> behavior of the old BDS. Besides, Xen doesn't support fw_cfg and pflash, >>> so it is really a headache to change the boot order in Xen :( >>> With the current order, the Xen HVM always ran into the shell instead of >>> DVD or the hard disk if there was no one to interfere. Lowering the >>> priority of shell gives the block devices the chance to boot at least. >>> I know the best solution is to make Xen support both fw_cfg and pflash, >>> but it seems not going to happen in the short term. >> >> I think this makes sense. >> >> However, in this case it's not just the UEFI shell, but also the memory >> mapped UiApp application (practically the setup UI). If you move one to >> the end, you should probably move the other one as well. >> > We don't have to move UiApp. The attribute of UiApp has is > "LOAD_OPTION_CATEGORY_APP | LOAD_OPTION_ACTIVE | LOAD_OPTION_HIDDEN" > and BootBootOptions will just ignore UiApp. It only will be triggered by > the hotkeys or OsIndications.
Nice. Thanks for tracking this down. > >> Gary, can you please submit a patch that works for you, CC'ing Ray in >> addition to the OvmfPkg maintainers? The new BDS is, well, pretty new in >> OvmfPkg, so for now I'd like some help from Ray in reviewing such changes. >> > Ok, I am working on it and will submit a patch later. > >> ... The problem I see here is that PlatformBootManagerBeforeConsole() >> *should* be exited with those boot options (and their hotkeys!) >> existing. Namely, right after PlatformBootManagerBeforeConsole() returns >> to BdsEntry(), you can see a call to EfiBootManagerStartHotkeyService(). >> I think by that time the hotkeys (and their boot options) must be in >> place already. >> >> So, I believe the right to do is *not* to postpone the registration >> until AfterConsole. Instead, how about de-registering those two options >> right before EfiBootManagerRefreshAllBootOption(), and re-adding them >> right after EfiBootManagerRefreshAllBootOption()? >> >> Also, since this may have a performance impact, I would prefer if this >> de-register / re-register logic was restricted to Xen only. More >> precisely, call QemuFwCfgIsAvailable() -- it's not about Xen >> specifically; we want to know if SetBootOrderFromQemu() will have a >> chance to do anything. >> > Since the order of UiApp doesn't matter, we don't have to worry about > the hotkeys. Do you have any other concern about the delayed registration > of the shell? No, it's fine; I've just R-b'd your patch (and would like to see Ray okay it too). Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
