Messages in this thread | | | Date | Thu, 12 Oct 2023 14:28:31 +0300 | Subject | Re: [PATCH] x86/efistub: Don't try to print after ExitBootService() | From | Nikolay Borisov <> |
| |
On 12.10.23 г. 13:14 ч., kirill.shutemov@linux.intel.com wrote: > On Wed, Oct 11, 2023 at 10:25:28PM +0300, Nikolay Borisov wrote: >> setup_e820() is executed after UEFI's ExitBootService has been called. >> This causes the firmware to throw an exception because Console IO >> protocol handler is supposed to work only during boot service >> environment. As per UEFI 2.9, section 12.1: >> >> "This protocol isused to handle input and output of text-based >> information intended for the system user during the operation of code >> in the boot services environment." >> >> Running a TDX guest with TDVF with unaccepted memory disabled results in >> the following output: > > Oh. My bad. > > But there's other codepath that does the same. If setup_e820() fails with > EFI_BUFFER_TOO_SMALL, efi_stub_entry() would try to print "exit_boot() > failed\n". > > I wouldner if it is feasible to hook up earlyprintk console into > efi_printk() machinery for after ExitBootService() case? Silent boot > failure is not the best UX. >
So looking at the code the only thing which would prevent refactoring to exit logic to directly call exit_boot_func etc and setup_e820 before calling efi_exit_boot_services is if the memory map changes. The current code ensures that we really have the latest memory map version and so setup_e820 is called with the latest version.
Ard, how likely it is that the memory map can indeed change between the calls to getmemorymap and exitbootservice?
| |