"Huang, Ying" <[email protected]> writes:
> On Mon, 2007-07-30 at 22:40 -0600, Eric W. Biederman wrote:
>> "Huang, Ying" <[email protected]> writes:
>>
>> > This patch adds document for EFI x86_64 support. The boot parameters
>> > added are documented in Documentation/i386/zero-page.txt. The setup
>> > and operation guide of EFI based system is documented in
>> > Documentation/x86_64/uefi.txt.
>> >
>> > Signed-off-by: Chandramouli Narayanan <[email protected]>
>> > Signed-off-by: Huang Ying <[email protected]>
>> >
>> > ---
>> >
>> > i386/zero-page.txt | 18 ++++++++++++++----
>> > x86_64/uefi.txt | 42 ++++++++++++++++++++++++++++++++++++++++++
>> > 2 files changed, 56 insertions(+), 4 deletions(-)
>> >
>> > Index: linux-2.6.23-rc1/Documentation/i386/zero-page.txt
>> > ===================================================================
>> > --- linux-2.6.23-rc1.orig/Documentation/i386/zero-page.txt 2007-07-30
>> > 11:28:45.000000000 +0800
>> > +++ linux-2.6.23-rc1/Documentation/i386/zero-page.txt 2007-07-30
>> > 11:29:28.000000000 +0800
>> > @@ -31,11 +31,11 @@
>> > 0xb0 - 0x13f Free. Add more parameters here if you really need them.
>> > 0x140- 0x1be EDID_INFO Video mode setup
>> >
>> > -0x1c4 unsigned long EFI system table pointer
>> > -0x1c8 unsigned long EFI memory descriptor size
>> > -0x1cc unsigned long EFI memory descriptor version
>> > +0x1c4 unsigned long EFI system table pointer*
>> > +0x1c8 unsigned long EFI memory descriptor size*
>> > +0x1cc unsigned long EFI memory descriptor version*
>> > 0x1d0 unsigned long EFI memory descriptor map pointer
>> > -0x1d4 unsigned long EFI memory descriptor map size
>> > +0x1d4 unsigned long EFI memory descriptor map size*
>> > 0x1e0 unsigned long ALT_MEM_K, alternative mem check, in Kb
>> > 0x1e4 unsigned long Scratch field for the kernel setup code
>> > 0x1e8 char number of entries in E820MAP (below)
>> > @@ -87,3 +87,13 @@
>> > 0x2d0 - 0xd00 E820MAP
>> > 0xd00 - 0xeff EDDBUF (edd.S) for disk signature read sector
>> > 0xd00 - 0xeeb EDDBUF (edd.S) for edd data
>> > +
>> > +Changes for x86_64 implementation:
>> > +---------------------------------
>> > +For alignment purposes, the following parameters are rearranged.
>> > +
>> > +0x1b8 unsigned long EFI system table pointer
>> > +0x1c0 unsigned long EFI Loader signature
>> > +0x1c4 unsigned long EFI memory descriptor size
>> > +0x1c8 unsigned long EFI memory descriptor version
>> > +0x1cc unsigned long EFI memory descriptor map size
>>
>> Huh? It is the same protocol. Unless there are specific issues such
>> as pointers being to small we should remain 100% the same for both
>> arch/i386 and arch/x86_64 This variation looks like a serious
>> bug.
>
> The parameters are rearranged, because the pointer is too small. For
> example, the EFI system table pointer is 8 bytes in x86_64, while it is
> 4 bytes in i386.
Ok. I see what is happening. When the documentation is for arch/i386
unsigned long is 4 bytes, and you are using unsigned long to mean 8
bytes. For an 8 byte fields please just spell out the size as 8
bytes.
How does EFI handle 32bit/64bit compatibility? In particular
how do I load a 32bit kernel on machine with a 64bit EFI? Can
it be done?
Eric
On Thu, 2007-08-02 at 01:16 +0800, Eric W. Biederman wrote:
> > The parameters are rearranged, because the pointer is too small. For
> > example, the EFI system table pointer is 8 bytes in x86_64, while it
> is
> > 4 bytes in i386.
>
> Ok. I see what is happening. When the documentation is for arch/i386
> unsigned long is 4 bytes, and you are using unsigned long to mean 8
> bytes. For an 8 byte fields please just spell out the size as 8
> bytes.
Ok. Will do in the next version.
>
> How does EFI handle 32bit/64bit compatibility? In particular
> how do I load a 32bit kernel on machine with a 64bit EFI? Can
> it be done?
>
Because the EFI memory map is converted to E820 map in bootloader now,
it is possible to load 32bit kernel on machine with a 64bit EFI. But it
is almost impossible to call EFI runtime service in 32bit kernel. But I
think EFI runtime service is not essential in this situation, because
the raw hardware can be used too.
Best Regards,
Huang Ying
On Tuesday 07 August 2007 11:29:44 Huang, Ying wrote:
> > How does EFI handle 32bit/64bit compatibility? In particular
> > how do I load a 32bit kernel on machine with a 64bit EFI? Can
> > it be done?
> >
> Because the EFI memory map is converted to E820 map in bootloader now,
> it is possible to load 32bit kernel on machine with a 64bit EFI.
The 32bit EFI code doesn't know this yet, does it?
> But it
> is almost impossible to call EFI runtime service in 32bit kernel. But I
> think EFI runtime service is not essential in this situation, because
> the raw hardware can be used too.
That doesn't sound good. Is this really supposed to work this way?
If the raw hardware works why are we using EFI services at all?
We generally trust hardware more than BIOSes.
Might we end up with machines that only boot with the 64bit kernel?
Will systems have a dual EFI implementation?
Also long term I would like to use a few useful EFI services,
like the support to put some data into the CMOS area to survive
a reboot. That would be quite useful for panics and oopses.
But we would prefer to have that on 32bit too.
-Andi
On Tue, 2007-08-07 at 11:54 +0200, Andi Kleen wrote:
> On Tuesday 07 August 2007 11:29:44 Huang, Ying wrote:
>
> > > How does EFI handle 32bit/64bit compatibility? In particular
> > > how do I load a 32bit kernel on machine with a 64bit EFI? Can
> > > it be done?
> > >
> > Because the EFI memory map is converted to E820 map in bootloader now,
> > it is possible to load 32bit kernel on machine with a 64bit EFI.
>
> The 32bit EFI code doesn't know this yet, does it?
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
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
> > But it
> > is almost impossible to call EFI runtime service in 32bit kernel. But I
> > think EFI runtime service is not essential in this situation, because
> > the raw hardware can be used too.
>
> That doesn't sound good. Is this really supposed to work this way?
>
> If the raw hardware works why are we using EFI services at all?
> We generally trust hardware more than BIOSes.
>
> Might we end up with machines that only boot with the 64bit kernel?
>
> Will systems have a dual EFI implementation?
I don't know. But I can ask some EFI guys about this.
> Also long term I would like to use a few useful EFI services,
> like the support to put some data into the CMOS area to survive
> a reboot. That would be quite useful for panics and oopses.
> But we would prefer to have that on 32bit too.
Yes, although oopses and panics information can be saved though kdump
too, it is more convenient to use EFI variable services to store
information like that especially for ordinary user.
Best Regards,
Huang Ying
> 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.
Or did you apply more patches?
-Andi
>-----Original Message-----
>From: Andi Kleen [mailto:[email protected]]
>Subject: Re: [PATCH 5/5] x86_64 EFI support -v3: EFI document
>> 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?
Yes.
>> 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.
I have not tested elilo. I use another x86_64 EFI boot loader (it will
be released soon), but elilo works in the same way, and I will test
elilo later. The 16bit entry of kernel (arch/(i386|x86_64)/boot/setup.S)
is not used by elilo. Instead, elilo collects the needed information
defined in include/asm-x86_64/bootsetup.h itself, and passes it to
kernel 32bit entry (arch/(i386|x86_64)/boot/compressed/head.S). For E820
map, the elilo converts the EFI memory map to E820 map in "boot
parameters memory" which is copied to "boot_params" or "x86_boot_params"
by Linux kernel later.
>Or did you apply more patches?
No, just the frame buffer patch.
Best Regards,
Huang Ying
> Instead, elilo collects the needed information
> defined in include/asm-x86_64/bootsetup.h itself,
That's nasty. I must have missed when we declared this a public ABI.
It's not really designed to be one. Was there public discussion on this?
I expect we'll have some grief from this in the future.
If it's really done this way we should at least add a version
number and a boot loader ID like the standard boot protocol
so that bugs later can be worked around. Also some Documentation
would be good. And comments. But discussion first.
-Andi
On 8/8/07, Andi Kleen <[email protected]> wrote:
> > Instead, elilo collects the needed information
> > defined in include/asm-x86_64/bootsetup.h itself,
>
> That's nasty. I must have missed when we declared this a public ABI.
> It's not really designed to be one. Was there public discussion on this?
Maybe What I said is not clear and correct. In fact, the elilo follows
the boot protocol defined in Documentation/i386/zero-page.txt, just
not uses arch/(i386|x86_64)/boot/setup.S to collect the information,
but collects them by elilo itself. Information in
include/asm-x86_64/bootsetup.h is just a part of that in
Documentation/i386/zero-page.txt.
> I expect we'll have some grief from this in the future.
>
> If it's really done this way we should at least add a version
> number and a boot loader ID like the standard boot protocol
> so that bugs later can be worked around. Also some Documentation
> would be good. And comments. But discussion first.
>
Is what defined in Documentation/i386/zero-page.txt the standard boot
protocol. If it is, the elilo follows it. My previous expressing is
not clear and correct.
Best Regards,
Huang Ying
Andi Kleen <[email protected]> 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.
On Wednesday 08 August 2007 17:11:54 huang ying wrote:
> On 8/8/07, Andi Kleen <[email protected]> wrote:
> > > Instead, elilo collects the needed information
> > > defined in include/asm-x86_64/bootsetup.h itself,
> >
> > That's nasty. I must have missed when we declared this a public ABI.
> > It's not really designed to be one. Was there public discussion on this?
>
> Maybe What I said is not clear and correct. In fact, the elilo follows
> the boot protocol defined in Documentation/i386/zero-page.txt,
No that's not the boot protocol. The boot protocol is in Documentation/i386/boot.txt
> just
> not uses arch/(i386|x86_64)/boot/setup.S to collect the information,
> but collects them by elilo itself. Information in
> include/asm-x86_64/bootsetup.h is just a part of that in
> Documentation/i386/zero-page.txt.
That's an internal interface that is not really suitable to use
by other programs. e.g. it is not extensible (unlike the boot protocol)
-Andi
>
> 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.
kexec can use it because it's in tree.
But I don't think using it by out of tree stuff is a good idea.
e.g. assuming we need a new field. How would we extend this?
There is no version number or anything to detect this.
For in tree code it can be just updated. But weirdo-EFI-boot loader
cannot.
-Andi
Andi Kleen <[email protected]> writes:
>>
>> 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.
>
> kexec can use it because it's in tree.
Not the part that actually uses it.
> But I don't think using it by out of tree stuff is a good idea.
>
> e.g. assuming we need a new field. How would we extend this?
> There is no version number or anything to detect this.
>
> For in tree code it can be just updated. But weirdo-EFI-boot loader
> cannot.
So far the logic has been.
Inspect bzImage. And get boot protocol version.
If field we need for returning data is not supported do not give
data. Or something like that. Usually the fields always exist
and you can just fill them in and we only append to the boot
protocol structure.
In practice this has been working for the last 7 years or so,
for EFI, and LinuxBIOS, and kexec, and Gujin and I don't remember what
else.
It isn't the prettiest thing in the world but it works and everybody
who needs it uses it. Which tend to be the important parts for a
standard.
Eric