Re: [PATCH] x86, efi: retry ExitBootServices() on failure
From: H. Peter Anvin
Date: Wed Jun 19 2013 - 04:54:14 EST
The 0xa0000 restriction applies to BIOS really...
"matt@xxxxxxxxxxxxxxxxx" <matt@xxxxxxxxxxxxxxxxx> wrote:
>On Tue, 18 Jun, at 10:12:22PM, Zachary Bobroff wrote:
>> > Okay, I'm fine with that aspect then. Let's hope everyone plays by
>> > that rule.
>> This is all according to specification, so if they are not following
>> these rules they should be corrected. The link to where the current
>> public version of the specification is available is here:
>While I agree that the vendor should be informed if their
>deviates from the spec in some way, the Linux kernel usually still
>to support these nonconforming machines once they end up in the hands
>consumers (which is often the point at which we discover these kinds of
>issues). Sadly, we're still not in a position where firmware updates
>be applied from OEMs ubiquitously, either because machines are End of
>Life'd or because the update needs to be run from Windows.
>We tend to adopt the approach of: let's try this until we get reports
>a class of machines where this solution doesn't work.
>Though I do find it refreshing to hear engineers talking about the UEFI
>spec in such black and white terms. That is certainly the ideal we
>should be aiming for.
>> > Why by one? Splitting some 'free memory' block may result in an
>> > increase by more then one afaict. Assuming the increment can only
>> > one is >implying you having knowledge of the allocator
>> > implementation and behavior, which shouldn't be made use of in
>> > kernel code.
>> We had to actually increment it by two to get it to work correctly.
>> This is all based upon the use of the low_alloc routine in the linux
>> kernel file. I agree there is still some outstanding issue based
>> this, but we put it through several different types of tests and it
>> continued to work correctly. The truest solution would be to us the
>> AllocateMaxAddress parameter when using AllocatePages.
>> It was my understanding that the point of this was to allocate the
>> memory map below a certain address in memory because the kernel
>> required it. Matt, can you comment here? I am not aware of what
>> address it needs to be below, but using this function should do the
>> trick. Also, if you want to inform me better of what memory ceiling
>> restrictions there are at this early stage of the kernel, I can
>> rewrite the file without the need of the low_alloc routine entirely.
>The most important restriction is that all allocations in the EFI boot
>stub need to be below the 1GB mark, because only the first 1GB of
>virtual memory is mapped, unless certain flags are set in the
>field of the boot_params header. See Documentation/x86/boot.txt.
>Further to that, I think I remember some restrictions on the location
>the cmdline pointer - that it needs to be below 0xa0000. Again,
>Documentation/x86/boot.xt should have all the info you need.
Sent from my mobile phone. Please excuse brevity and lack of formatting.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/