lkml.org 
[lkml]   [2023]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] x86/efistub: Don't try to print after ExitBootService()
From


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?

\
 
 \ /
  Last update: 2023-10-12 13:29    [W:0.096 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site