> On Aug 1, 2018, at 11:33 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>
> On 1 August 2018 at 19:07, Jeffrey Hugo <jh...@codeaurora.org> wrote:
>> On 8/1/2018 10:27 AM, Eric Snowberg wrote:
>>> Once EBS is called, there isn’t enough room available for the new memory
>>> map on a very large system (do to the memory that was previously allocated
>>> in exit_boot_func).
>>>
>>> The race condition that exists between priv_func and the call to EBS will
>>> be taken care of by the existing code, thru the slack slots.
>>
>>
>> Now I'm slightly confused. There isn't an issue because of slack slots?
>>
>> I'm kind of wondering if our assumption that 8 slots would be enough is not
>> invalid, and therefore we need to increase that number. I hate kicking the
>> can down the road like that, but as discussed in 2016, there doesn't seem to
>> be a good alternative.
>>
>
> But why does alloc_e820ext have to be deferred to the last minute?
I didn’t understand that either. If it was done earlier, I assume there would
not be a problem.
Our tests show any kernel prior to Commit d64934019f6c ("x86/efi: Use
efi_exit_boot_services()”) will boot successfully. The first "goto get_map"
that was removed from the previous exit_boot insured their was enough room for
the memory map when EBS was called.
Which would you rather see done? Increase the slack number or move the e820
code? I can look at doing either if you'd like.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
