Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

[Ingo Molnar <mingo@kernel.org>]

* Borislav Petkov <bp@alien8.de> wrote:

> On Fri, May 31, 2013 at 01:06:09PM +0200, Jiri Kosina wrote:
> >
> > (*) If one would be naive enough, he'd believe that the pressure 
> > should be put on the BIOS writers instead of OS to fix the bug :)
> 
> Oh, definitely pressure on BIOS dudes. If they're in violation of the 
> spec and they still can fix it in time, they better. I'm sick and tired 
> of having to deal with BIOS idiocy in kernel code.

I'm all for some BIOS quality bashing, but the reality is:

1) It's not just about SGI/UV systems but apparently about several 
   different types of x86 laptops produce the same boot crash pattern: 
   most of which come from manufacturers that simply don't care about 
   Linux all that much.

   So by not reverting we'd screw our users, not put any recognizable 
   pressure on any BIOS writers or manufacturers.

2) Obviously Windows does not crash, and that's what most laptops test.
   So our realistic 'spec target' is not some sort of pure 'EFI spec',
   but EFI implementations _tested under Windows_. Consider it an 
   'extended EFI compatibility spec'.

3) There's a better, more robust firmware environment approach being 
   worked on (by you?) that avoids such 1:1 physical mapping assumption 
   crashes. That's something worth doing anyway, so why not delay the 
   early QueryVariableInfo() call change to when that enviroment is 
   properly implemented?

4) The revert is easy, and the functionality the original patch provided
   was a marginal increase in debug output to begin with...

So to me the right approach seems to be:

 A: revert now for v3.10
 B: implement 1:1 mappings environment for firmware, for v3.11
 C: reintroduce the early QueryVariableInfo() call again, in v3.11

Thanks,

	Ingo