Re: [PATCH 5/5] x86_64 EFI support -v3: EFI document

[ebiederm@xmission.com (Eric W. Biederman)]

Andi Kleen <ak@suse.de> writes:

>> The needed code changing is minimal. In fact, I can boot 32bit Linux
>> kernel on my x86_64 EFI machine. With setup as follow:
>>
>> 1. Apply the efi-fb.patch
> Just for the frame buffer, right?
>
>> 2. make efi fb driver not depend on EFI
>> 3. configure kernel as follow:
>>    a. CONFIG_EFI is turned off
>>    b. CONFIG_FB_EFI is turned on
>
> Hmm, how does the 32bit kernel know where the e820 map is passed then?
> With CONFIG_EFI turned off it will just ask the real mode BIOS I think
> and I doubt elilo simulates that.

This is the classic skip the 16bit code and enter the kernel
in 32bit mode filling in the fields that the 16bit mode code would
have filled in the same way approach.

It isn't clearly documented as a public interface but is the way
everything without a classic x86 BIOS has been booting for quite a
while.  We can even reasonably handle Xen & lguest this way.  Dotting
the last couple of i's and crossing the last couple of t's is a pain
to make it a really solid and documented interface but I haven't
seen any real opposition to it.



On the other side since EFI doesn't not seem to have dual mode
interfaces I think this thread makes a very good case for not using
efi_enter_virtual_mode.  Always using a trampoline and keeping EFI
at it's original physical addresses. 

A trampoline switching to physical mode and maybe doing a 32->64
or 64->32 bit mode switch isn't that hard and should not be noticeably
slower then anything else.  Plus it makes EFI much more useful.


I agree with Andi that the variable services are more interesting
then reboots or setting the CMOS both of which we can talk to the
hardware directly to handle.

Eric

p.s.  On future patches that update the x86 boot protocol please
also copy HPA.  Thanks.