Message-ID: <20130619084329.GA5386@console-pimps.org>
Date:	Wed, 19 Jun 2013 09:43:29 +0100
From:	"matt@...sole-pimps.org" <matt@...sole-pimps.org>
To:	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>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86, efi: retry ExitBootServices() on failure

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.

-- 
Matt Fleming, Intel Open Source Technology Center
--
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