Message-ID: <298f16e6-7ada-4f2e-8dae-f3919e7c8225@email.android.com>
Date:	Wed, 19 Jun 2013 01:53:28 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"matt@...sole-pimps.org" <matt@...sole-pimps.org>,
	Zachary Bobroff <zacharyb@....com>
CC:	"'Jan Beulich'" <jbeulich@...e.com>,
	"matt.fleming@...el.com" <matt.fleming@...el.com>,
	"mjg59@...f.ucam.org" <mjg59@...f.ucam.org>,
	Joey Lee <JLee@...e.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] x86, efi: retry ExitBootServices() on failure

The 0xa0000 restriction applies to BIOS really...

"matt@...sole-pimps.org" <matt@...sole-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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists