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

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

[Huang, Ying]

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 <mouli@linux.intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>

---

 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
Index: linux-2.6.23-rc1/Documentation/x86_64/uefi.txt
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.23-rc1/Documentation/x86_64/uefi.txt	2007-07-30 11:29:28.000000000 +0800
@@ -0,0 +1,42 @@
+General note on [U]EFI x86_64 support
+-------------------------------------
+
+This provides documentation on [U]EFI support for x86_64 architecture.
+The nomenclature EFI and UEFI are used intechangeably in this document.
+
+Although the tools below are _not_ needed for building the kernel,
+the needed bootloader support and associated tools for x86_64 platforms
+with EFI firmware and specifications are listed below.
+
+1. UEFI specification:  http://www.uefi.org
+
+2. Booting EFI64 enabled kernel requires boot loader support.
+Patches to elilo and gnu-efi library with x86_64 support and documentation
+have been submitted to respective project maintainers.
+	elilo: http://sourceforge.net/projects/elilo
+	gnu-efi library: http://sourceforge.net/projects/gnu-efi/
+	gnu-efi-3.0d release now supports [U]EFI x86_64.
+
+3. The tool to convert ELF to PE-COFF image:
+	binutils-2.17.50.0.14 supports Intel64 EFI.
+	see http://www.kernel.org/pub/linux/devel/binutils/
+	[ elilo/gnu-efi with x86_64 support need this binutils support ]
+
+4. x86_64 platform with EFI/UEFI firmware.
+
+Mechanics:
+---------
+- Apply the EFI64 kernel patches and build with the following configuration.
+	CONFIG_EFI=y
+	EFI_FB=y
+	CONFIG_FRAMEBUFFER_CONSOLE=y
+	CONFIG_EFI_VARS=y
+
+- Create a VFAT partition on the disk
+- Copy the following to the VFAT partition:
+	elilo bootloader with x86_64 support and elilo configuration file
+	efi64 kernel image and initrd. Instructions on building elilo
+	and its dependencies can be found in the elilo sourceforge project.
+- Boot to EFI shell and invoke elilo choosing efi64 kernel image
+- On UEFI2.0 firmware systems, pass vga=normal for boot messages to show up
+  console. You can pass along the 'resume' boot option to test suspend/resume.

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

[Eric W. Biederman]

"Huang, Ying" <ying.huang@intel.com> 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 <mouli@linux.intel.com>
> Signed-off-by: Huang Ying <ying.huang@intel.com>
>
> ---
>
>  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.

Eric

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

[Huang, Ying]

On Mon, 2007-07-30 at 22:40 -0600, Eric W. Biederman wrote:
> "Huang, Ying" <ying.huang@intel.com> 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 <mouli@linux.intel.com>
> > Signed-off-by: Huang Ying <ying.huang@intel.com>
> >
> > ---
> >
> >  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.

Best Regards,
Huang Ying

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

[Eric W. Biederman]

"Huang, Ying" <ying.huang@intel.com> writes:

> On Mon, 2007-07-30 at 22:40 -0600, Eric W. Biederman wrote:
>> "Huang, Ying" <ying.huang@intel.com> 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 <mouli@linux.intel.com>
>> > Signed-off-by: Huang Ying <ying.huang@intel.com>
>> >
>> > ---
>> >
>> >  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

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

[Huang, Ying]

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

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

[Andi Kleen]

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

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

[Huang, Ying]

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

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

[Andi Kleen]

> 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

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

[Huang, Ying]

>-----Original Message-----
>From: Andi Kleen [mailto:ak@suse.de]
>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

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

[Andi Kleen]

> 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

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

[huang ying]

On 8/8/07, Andi Kleen <ak@suse.de> 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

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

[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.

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

[Andi Kleen]

> 
> 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

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

[Andi Kleen]

On Wednesday 08 August 2007 17:11:54 huang ying wrote:
> On 8/8/07, Andi Kleen <ak@suse.de> 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

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

[Eric W. Biederman]

Andi Kleen <ak@suse.de> 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

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

[Etienne Lorrain]

Eric W Biederman wrote:
> >> 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.
> > ......
> >
> > 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.

 Note that Gujin has a simple problem by using that 32 bits entry point:
there is no way to detect if the bzImage is compiled for 32 bits or 64 bits,
and Linux-real-mode calls a BIOS service for 64 bits only (to tell the BIOS you
are going to 64 bits - interrupt not really documented).
 Gujin can now be set to start at the 16 bits entry point, and load ELF32/ELF64
where you now the target word size, but the 32 bits entry point will "forget"
to call that service if the Linux kernel is 64 bits.
 The 32 bits entry point can still be used (-p parameter of tiny.exe) because
there seems to be a problem using the 16 bits entry point under DOS, at least
the old assembly version of the code - no more details known.

 Etienne.


      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

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

[Andi Kleen]

>  Note that Gujin has a simple problem by using that 32 bits entry point:

There is really no 32bit entry point today usable for external users. Or rather
it might by chance work today, but if we change the zero page (and there
is no guarantee it'll not be changed). I can pretty much guarantee it'll
be changed at some point. And you'll break if you use it.

kexec can use the 32bit entry, but only because it is in tree so it can be fixed 
up for any changes.

If you want to use it you would need to define some versionable protocol
first similar to the real mode boot protocol. That would require some work
and some thought to make sure it is forwards and backwards compatible.

I'll add a comment to zero-page.txt to make this more clear. Just because
something is documented in Documentation doesn't mean it's an external stable
ABI.

-Andi

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

[Etienne Lorrain]

--- Andi Kleen <ak@suse.de> wrote:
> >  Note that Gujin has a simple problem by using that 32 bits entry point:
> 
> There is really no 32bit entry point today usable for external users.

 That is why I added the 16 bits entry point support (selected by default),
my target with Gujin was not only to load Linux but also another simpler
format - gzip'ed ELF 32/64 files with real-mode embedded at address 0 .
 I also had to show that it was possible to write the Linux-real-mode
code in C with GCC so that someone else would do it and maintain it.
 I may (in few version) remove Gujin code which fills Linux zero-page
structure if the 16 bit entry point works in all cases (mostly in DOS
which help me to create a DBG debug file to sort out Gujin/BIOS problems
remotely).
 I may maintain another patch to produce this gzip'ed ELF32/64 for Linux
as an example of how to use that Gujin interface, but that is not really
related. That patch is in Gujin Sourceforge download.
 Note that I call (instead of jump to) the 16 bits entry point so that
this "function" can return to the bootloader if it detects a problem.

 Etienne.


      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

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

[huang ying]

On 8/9/07, Andi Kleen <ak@suse.de> wrote:
> There is really no 32bit entry point today usable for external users. Or rather
> it might by chance work today, but if we change the zero page (and there
> is no guarantee it'll not be changed). I can pretty much guarantee it'll
> be changed at some point. And you'll break if you use it.

Yes, there is no official 32bit external entry point. But on EFI
platform, the 16bit entry point can not be used because there is no
16bit BIOS call available. So, I think it is necessary to define a
32bit external entry point.

> kexec can use the 32bit entry, but only because it is in tree so it can be fixed
> up for any changes.

The kexec uses the 32bit entry point in a user space tool named
kexec-tools, not in the kernel.

> If you want to use it you would need to define some versionable protocol
> first similar to the real mode boot protocol. That would require some work
> and some thought to make sure it is forwards and backwards compatible.

I think at least the following should be done to make it a external
boot protocol.

1. A version number field should be added.
2. The pointers (especially these come from firmware) should be 64bit
to make the entry point can be used for both 32bit and 64bit platform.
3. More complete and formal document.

Can you kindly tell me what's more should be done?

Best Regards,
Huang Ying

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

[H. Peter Anvin]

huang ying wrote:
> 
> I think at least the following should be done to make it a external
> boot protocol.
> 
> 1. A version number field should be added.
> 2. The pointers (especially these come from firmware) should be 64bit
> to make the entry point can be used for both 32bit and 64bit platform.
> 3. More complete and formal document.
> 
> Can you kindly tell me what's more should be done?
> 

I have been looking at this recently, and also found that we already
have to make unacceptable compromises in order to fit into 4K, which is
set completely arbitrary (once upon a time, it was recycled as the
zeropage, but that is ancient history.)

Part of a formalizing the 32-bit/64-bit entrypoint involves a clean way
to extend this data set.

I mentioned in private email to a few people that I think a linked list
of tagged data items (similar to the way PCI capabilities work) would
probably make sense; we want a piece of code to know the structure
without needing to know the contents, in order to rescue data.

It's worth realizing that this is inherently never going to be as stable
as the real-mode entrypoint, and there is always going to be more
catch-up, simply because it's a broader interface.  What is blatantly
clear, however, is that the current structure is utterly ad hoc and has
been totally prematurely adopted as some sort of standard interface.
Since I've spent time formalizing the structure over the last few months
I've been rather horrified; it is truly as bad as you could get.

So, anyway, this has popped up on my radar already; it needs to happen
anyway so let's get the discussion started.

	-hpa

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

[Andi Kleen]

On Thursday 09 August 2007 16:09:23 huang ying wrote:
> On 8/9/07, Andi Kleen <ak@suse.de> wrote:
> > There is really no 32bit entry point today usable for external users. Or rather
> > it might by chance work today, but if we change the zero page (and there
> > is no guarantee it'll not be changed). I can pretty much guarantee it'll
> > be changed at some point. And you'll break if you use it.
> 
> Yes, there is no official 32bit external entry point. But on EFI
> platform, the 16bit entry point can not be used because there is no
> 16bit BIOS call available. So, I think it is necessary to define a
> 32bit external entry point.

Ok. How do you collect all the data in the zero page then?
There's much more in there than just the memory map.

Anyways for EFI the best way is probably to define a EFI entry
point that does the same work as the real mode code today just
using EFI services.

And for kexec :- well need a proper protocol.

> 
> > kexec can use the 32bit entry, but only because it is in tree so it can be fixed
> > up for any changes.
> 
> The kexec uses the 32bit entry point in a user space tool named
> kexec-tools, not in the kernel.

Ah i didn't realize this. Ok then kexec is also quite broken.
Somehow this must have been missed this fundamental flaw when this code was 
reviewed.

> 
> > If you want to use it you would need to define some versionable protocol
> > first similar to the real mode boot protocol. That would require some work
> > and some thought to make sure it is forwards and backwards compatible.
> 
> I think at least the following should be done to make it a external
> boot protocol.
> 
> 1. A version number field should be added.
> 2. The pointers (especially these come from firmware) should be 64bit
> to make the entry point can be used for both 32bit and 64bit platform.

32bit pointers are not too bad; it needs to be all physical anyways
because kernel virtual mapping can change any time.

> 3. More complete and formal document.
> 
> Can you kindly tell me what's more should be done?

It's a minimum start. But at least for EFI I still think it's better
to just move that code back into the kernel. Just cleanly separated.

-Andi

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

[H. Peter Anvin]

Andi Kleen wrote:
> 
> Ah i didn't realize this. Ok then kexec is also quite broken.
> Somehow this must have been missed this fundamental flaw when this code was 
> reviewed.
> 

It wasn't missed.  It was given the "there is no other way" defence, and
somehow that was considered sufficient.

Now, one could argue that kexec can just pass the boot_params from the
previous kernel boot, except there is no way to read them out, and so
it's not how it actually works.

	-hpa

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

[Huang, Ying]

On Thu, 2007-08-09 at 19:01 +0200, Andi Kleen wrote:
> > Yes, there is no official 32bit external entry point. But on EFI
> > platform, the 16bit entry point can not be used because there is no
> > 16bit BIOS call available. So, I think it is necessary to define a
> > 32bit external entry point.
> 
> Ok. How do you collect all the data in the zero page then?
> There's much more in there than just the memory map.

Now all the data in the zero page and standard boot protocol are
collected by the EFI bootloader. The EFI bootloader does this through
calling the EFI boot services. If the data is intended to be collected
in kernel setup code, the EFI boot services must be used inside kernel
setup code to collect the data.

> Anyways for EFI the best way is probably to define a EFI entry
> point that does the same work as the real mode code today just
> using EFI services.

So, for booting Linux kernel on EFI platform, the process you proposed
(named process A in the letter) will be as follow:

1. Bootloader loads the Linux kernel image into memory
2. Bootloader setups the parameter defined in standard boot protocol
(need some extension for EFI)
3. Bootloader jumps to kernel EFI 32bit/64bit entry point
4. Kernel EFI setup code collects the data in the zero pages through
calling the EFI boot services
5. Kernel EFI setup code jumps to decompressor entry point
6. Kernel decompressor jumps to kernel entry point (startup_64), which
then jumps to x86_64_start_kernel
7. The EFI memory map is converted to E820 map in x86_64_start_kernel,
and the result is stuffed into zero page.
8. Kernel booting up continues with the E820 map and other data of zero
page.

The process of current EFI implementation (named process B in the
letter) is as follow:

1. Bootloader loads the Linux kernel image into memory
2. Bootloader setups the parameter defined in standard boot protocol
3. Bootloader collects the data in the zero pages through calling the
EFI boot services
4. Bootloader converts EFI memory map to E820 map, the result is stuffed
into zero page.
5. Bootloader jumps to kernel decompressor entry point
6. Kernel decompressor jumpto kernel entry point (startup_64), which
jumps to x86_64_start_kernel
7. Kernel booting up continues with the E820 map and other data of zero
page.

Compares the above two process, we can find that the main difference
lies in:
1. Boot protocol. The process A uses standard boot protocol with some
EFI extension + EFI 32bit. The process B uses the standard boot protocol
+ zero page protocol (which is internal now).
2. In process A, the zero page data setupping and E820 converting are
done by kernel, while in process B, these are done done by bootloader.

The advantages of process A:
1. The zero page protocol can be made internal, so it is more
extensible.

The advantages of process B:
1. The EFI boot support code of Linux kernel is minimal. In fact,
current EFI boot support patch only adds a frame buffer driver. And I do
not see any more needed except some firmware information (ACPI root
pointer, SMBIOS pointer, etc) maybe need to be passed through zero page.

The issues of process A:
1. To support multiple BIOS/bootloader with one kernel binary image,
multiple setup binaries must be integrated into kernel binary image. At
end, the layout of the bzImage of Linux kernel may become as follow:
bootsect + lagacy BIOS setup + EFI32 setup + EFI64 setup + LinuxBIOS
setup + kexec setup + decompressor + vmlinux binary
That is, there is one "setup" for each BIOS type. Because the EFI32 and
EFI64 is not bianry compatible, two EFI setup is needed at least for
i386 kernel.

> And for kexec :- well need a proper protocol.

It seems that the only way for kexec is to use the standard boot
protocol + zero page protocol. If this is true, the zero page protocol
should be made external, so EFI can use it too.

> > > kexec can use the 32bit entry, but only because it is in tree so
it can be fixed
> > > up for any changes.
> > 
> > The kexec uses the 32bit entry point in a user space tool named
> > kexec-tools, not in the kernel.
> 
> Ah i didn't realize this. Ok then kexec is also quite broken.
> Somehow this must have been missed this fundamental flaw when this
code was 
> reviewed.
> 
> > 
> > > If you want to use it you would need to define some versionable
protocol
> > > first similar to the real mode boot protocol. That would require
some work
> > > and some thought to make sure it is forwards and backwards
compatible.
> > 
> > I think at least the following should be done to make it a external
> > boot protocol.
> > 
> > 1. A version number field should be added.
> > 2. The pointers (especially these come from firmware) should be
64bit
> > to make the entry point can be used for both 32bit and 64bit
platform.
> 
> 32bit pointers are not too bad; it needs to be all physical anyways
> because kernel virtual mapping can change any time.

Yes, all pointers should be physical. But some pointers come from
firmware such as ACPI root pointer, EFI system table pointer should be
64bit, because we can not control the actual position pointed to.
 
> > 3. More complete and formal document.
> > 
> > Can you kindly tell me what's more should be done?
> 
> It's a minimum start. But at least for EFI I still think it's better
> to just move that code back into the kernel. Just cleanly separated.

Best Regards,
Huang Ying