[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4] efi: Avoid calling boot services after ExitBootServices()



On 09/06/15 14:24, Ian Campbell wrote:
> On Tue, 2015-06-09 at 14:05 +0100, Ross Lagerwall wrote:
>> On 06/09/2015 01:53 PM, Ian Campbell wrote:
>>> On Tue, 2015-06-09 at 12:51 +0100, Jan Beulich wrote:
>>>>>>> On 09.06.15 at 12:36, <ross.lagerwall@xxxxxxxxxx> wrote:
>>>>> ping
>>>> I'm still waiting for the ARM maintainers to ack ...
>>>>
>>>>>> --- a/xen/arch/arm/efi/efi-boot.h
>>>>>> +++ b/xen/arch/arm/efi/efi-boot.h
>>>>>> @@ -522,6 +522,11 @@ static void __init efi_arch_blexit(void)
>>>>>>            efi_bs->FreePool(memmap);
>>>>>>    }
>>>>>>
>>>>>> +static void __init efi_arch_halt(void)
>>>>>> +{
>>>>>> +    stop_cpu();
>>>>>> +}
>>>>>> +
>>>>>>    static void __init efi_arch_load_addr_check(EFI_LOADED_IMAGE 
>>>>>> *loaded_image)
>>>>>>    {
>>>>>>        if ( (unsigned long)loaded_image->ImageBase & ((1 << 12) - 1) )
>>>> ... this.
>>> I think it is ok, it does a bit more than the x86 variant, which is that
>>> it would interlock correctly with __cpu_die, where the open coded on x86
>>> wouldn't (assuming you have any interlock anyway.
>>>
>>> In terms of the rest of the patch, are those two places changed to use
>>> SystemTable->BootServices instead of efi_bs, if the point of the patch
>>> is to not use BootServices after exit is called?
>>>
>> GetMemoryMap() and ExitBootServices() are the only functions explicitly 
>> allowed after the first call to ExitBootServices() so they are called 
>> via SystemTable->BootServices. efi_bs is set to NULL to ensure that no 
>> other bootservices are called.
> I see. That might be worth a mention in the commit log?

The commit message does say this.  Is there anything you think needs
further clarification?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.