lkml.org 
[lkml]   [2013]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] x86, efi: retry ExitBootServices() on failure
From
Date
The 0xa0000 restriction applies to BIOS really...

"matt@console-pimps.org" <matt@console-pimps.org> 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:
>> http://www.uefi.org/specs/agreement
>
>While I agree that the vendor should be informed if their
>implementation
>deviates from the spec in some way, the Linux kernel usually still
>needs
>to support these nonconforming machines once they end up in the hands
>of
>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
>can
>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
>of
>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
>be
>> > 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
>upon
>> 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
>xloadflags
>field of the boot_params header. See Documentation/x86/boot.txt.
>
>Further to that, I think I remember some restrictions on the location
>of
>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.


\
 
 \ /
  Last update: 2013-06-20 19:21    [W:0.078 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site