[RFC] Best place/method to determine BIOS version?

[RFC] Best place/method to determine BIOS version?

[Alex Thorlton]

Hi guys,

We recently ran into/corrected a bug in our BIOS that was exposed by the
recent updates to the way that the EFI code maps in memory during boot.
Discussion here:

http://comments.gmane.org/gmane.linux.kernel/1638074

Anyways, we now need to find a way to determine the BIOS version before
efi_apply_memmap_quirks is called, so that we know whether or not the
BIOS we're running requires the quirk.  We have a function in one of our
EFI runtime services that provides this information, but I'm having a
lot of trouble calling this function early enough in boot.

It seems that all the necessary function pointers are available well
before efi_apply_memmap_quirks is called, but when trying to use
efi_call_phys6 to call our function, I always hit a kernel paging error.

I think the problem is that I really need to be doing this at a point
where I can directly use physical addressing (the function pointer that
we have stored in efi.uv_systab contains the physical address of our
function) - at least that's the idea I get from our BIOS guys, but I
really don't know what I'm talking about here :)

Can anybody help me with how early in boot I need to make this call, and
possibly with an appropriate location to stick the code in?

Any advice is greatly appreciated.  Thanks!

- Alex

Re: [RFC] Best place/method to determine BIOS version?

[Borislav Petkov]

On Mon, Jun 09, 2014 at 03:00:17PM -0500, Alex Thorlton wrote:
> Hi guys,
> 
> We recently ran into/corrected a bug in our BIOS that was exposed by the
> recent updates to the way that the EFI code maps in memory during boot.
> Discussion here:
> 
> http://comments.gmane.org/gmane.linux.kernel/1638074
> 
> Anyways, we now need to find a way to determine the BIOS version before
> efi_apply_memmap_quirks is called, so that we know whether or not the
> BIOS we're running requires the quirk.  We have a function in one of our
> EFI runtime services that provides this information, but I'm having a
> lot of trouble calling this function early enough in boot.
> 
> It seems that all the necessary function pointers are available well
> before efi_apply_memmap_quirks is called, but when trying to use
> efi_call_phys6 to call our function,

Why not use DMI instead of EFI for getting the BIOS version? I see
dmi_scan_machine() called earlier than efi_apply_memmap_quirks() in
setup_arch()...?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

efi_call on SGI

[Borislav Petkov]

Btw,

while we're at it, I see uv_bios_call is sometimes done with preemption
disabled around it and sometimes it is not (at least I don't see it)...

In any case, if SGI uses the EFI pagetable now too, you probably would
want to do the efi calls like the rest of x86 does them - see the 64-bit
version of efi_call_virt() in arch/x86/include/asm/efi.h for an example
what I mean.

Now, you could either copy that macro or you could accomodate it to
serve everyone's needs - depends on what you'd prefer.

I'm just saying - I had stumbled across this while the debugging session
was going on and wanted to point that out but it wasn't too important at
the time so...

HTH.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: efi_call on SGI

[Alex Thorlton]

On Tue, Jun 10, 2014 at 10:44:14PM +0200, Borislav Petkov wrote:
> Btw,
> 
> while we're at it, I see uv_bios_call is sometimes done with preemption
> disabled around it and sometimes it is not (at least I don't see it)...
> 
> In any case, if SGI uses the EFI pagetable now too, you probably would
> want to do the efi calls like the rest of x86 does them - see the 64-bit
> version of efi_call_virt() in arch/x86/include/asm/efi.h for an example
> what I mean.
> 
> Now, you could either copy that macro or you could accomodate it to
> serve everyone's needs - depends on what you'd prefer.
> 
> I'm just saying - I had stumbled across this while the debugging session
> was going on and wanted to point that out but it wasn't too important at
> the time so...

Thanks, Boris.  I'll take a look at that.  I'm not sure why we would've
chosen to do things differently there; wouldn't have been around for
that, but I'll see if we can fix things up so that we're doing
everything the way that everyone else is.

- Alex

Re: [RFC] Best place/method to determine BIOS version?

[Matt Fleming]

On Mon, 09 Jun, at 03:00:17PM, Alex Thorlton wrote:
> 
> I think the problem is that I really need to be doing this at a point
> where I can directly use physical addressing (the function pointer that
> we have stored in efi.uv_systab contains the physical address of our
> function) - at least that's the idea I get from our BIOS guys, but I
> really don't know what I'm talking about here :)

Can't you use either early_ioremap() or ioremap() (depending on when you
want to access the physical address), perhaps coupled with
efi_call_phys()?

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [RFC] Best place/method to determine BIOS version?

[Alex Thorlton]

On Wed, Jun 11, 2014 at 09:55:48AM +0100, Matt Fleming wrote:
> Can't you use either early_ioremap() or ioremap() (depending on when you
> want to access the physical address), perhaps coupled with
> efi_call_phys()?

I had actually tried that exact approach, but I think the problem is
that I need to remap both the function code, and the data that it needs
to access, and the pointers get clobbered in that process.  The pointers
work fine in direct physical mode, and they work fine after being mapped
into the EFI page table in virtual mode, but I think there's some magic
in there that helps fix them up when set_virtual_address_map is called,
which isn't getting done when I try to remap manually.

I'll look into this approach a bit more to be absolutely sure that it
won't work, but I hadn't had any luck so far.

- Alex