[PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol

[PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol

[Huang, Ying]

This patchset defines a 32-bit boot protocol for i386/x86_64 platform,
adds an extensible boot parameter passing mechanism, export the boot
parameters via sysfs.

The patchset has been tested against 2.6.23-rc8-mm2 kernel on x86_64
and i386.

This patchset is based on the proposal of Peter Anvin.


Known Issues:

- Where is safe to place the linked list of setup_data?  Because the
  length of the linked list of setup_data is variable, it can not be
  copied into BSS segment of kernel as that of "zero page". We must
  find a safe place for it, where it will not be overwritten by kernel
  during booting up. The i386 kernel will overwrite some pages after
  _end. The x86_64 kernel will overwrite some pages from 0x1000 on.

- The fields in zero page are fairly complex (such as struct
  edd_info). Is it necessary to document every field inside the first
  level fields, until the primary data type? Or is it sufficient to
  provide the C struct name only?


v5:

- Use bt_ioremap/bt_iounmap in copy_setup_data.

v4:

- Reserve setup_data and boot parameters for accessing during
  runtime.
- Export boot parameters via sysfs.

v3:

- Move hd0_info and hd1_info back to zero page for compatibility.

v2:

- Increase the boot protocol version number
- Check version number before parsing setup data.
- Revise zero page description according to the source code and move
  them to zero-page.txt.


Best Regards,
Huang Ying

Re: [PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol

[Huang, Ying]

Hi, Peter and Andi,

Do you think this patch set is ready for merging? Otherwise what I can
do to make it ready?

Best Regards,
Huang Ying

On Fri, 2007-10-12 at 13:52 +0800, Huang, Ying wrote:
> This patchset defines a 32-bit boot protocol for i386/x86_64 platform,
> adds an extensible boot parameter passing mechanism, export the boot
> parameters via sysfs.
> 
> The patchset has been tested against 2.6.23-rc8-mm2 kernel on x86_64
> and i386.
> 
> This patchset is based on the proposal of Peter Anvin.
> 
> 
> Known Issues:
> 
> - Where is safe to place the linked list of setup_data?  Because the
>   length of the linked list of setup_data is variable, it can not be
>   copied into BSS segment of kernel as that of "zero page". We must
>   find a safe place for it, where it will not be overwritten by kernel
>   during booting up. The i386 kernel will overwrite some pages after
>   _end. The x86_64 kernel will overwrite some pages from 0x1000 on.
> 
> - The fields in zero page are fairly complex (such as struct
>   edd_info). Is it necessary to document every field inside the first
>   level fields, until the primary data type? Or is it sufficient to
>   provide the C struct name only?
> 
> 
> v5:
> 
> - Use bt_ioremap/bt_iounmap in copy_setup_data.
> 
> v4:
> 
> - Reserve setup_data and boot parameters for accessing during
>   runtime.
> - Export boot parameters via sysfs.
> 
> v3:
> 
> - Move hd0_info and hd1_info back to zero page for compatibility.
> 
> v2:
> 
> - Increase the boot protocol version number
> - Check version number before parsing setup data.
> - Revise zero page description according to the source code and move
>   them to zero-page.txt.

Re: [PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol

[Huang, Ying]

On Fri, 2007-10-12 at 13:52 +0800, Huang, Ying wrote:
> Known Issues:
> 
> - Where is safe to place the linked list of setup_data?  Because the
>   length of the linked list of setup_data is variable, it can not be
>   copied into BSS segment of kernel as that of "zero page". We must
>   find a safe place for it, where it will not be overwritten by kernel
>   during booting up. The i386 kernel will overwrite some pages after
>   _end. The x86_64 kernel will overwrite some pages from 0x1000 on.

Do you think it is a good idea to check the collision between setup data
and memory area used during kernel boot through bootmem allocator? If
any memory area used by setup data is reserved in bootmem allocator by
some other kernel subsystem, there is a collision, otherwise, the setup
data should be safe.

Best Regards,
Huang Ying

Re: [PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol

[Andi Kleen]

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

> Do you think it is a good idea to check the collision between setup data
> and memory area used during kernel boot through bootmem allocator?

You can't solve this through bootmem because x86-64 allocates memory
in several places before bootmem (using functions in e820.c) Right now
this is quite hackish with hard coded areas to avoid conflicts.  But I
recently had a need to allocate more memory that early too and changed
the code to a generic early reservation interface. With that it would
be relatively easy to reserve.

-Andi

Re: [PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol

[Huang, Ying]

On Wed, 2007-10-17 at 10:25 +0200, Andi Kleen wrote:
> "Huang, Ying" <ying.huang@intel.com> writes:
> 
> > Do you think it is a good idea to check the collision between setup data
> > and memory area used during kernel boot through bootmem allocator?
> 
> You can't solve this through bootmem because x86-64 allocates memory
> in several places before bootmem (using functions in e820.c) Right now
> this is quite hackish with hard coded areas to avoid conflicts.  But I
> recently had a need to allocate more memory that early too and changed
> the code to a generic early reservation interface. With that it would
> be relatively easy to reserve.

Can you tell me what that early reservation interface is? What I find in
x86_64 that does early memory allocation is alloc_low_page, which gets
non-conflict memory area through e820 map.

Because setup data is allocated by bootloader or kernel 16-bit setup
code, and the e820 map is created there too, the memory area used by
setup data can be made reserved memory area in e820 map by bootloader or
kernel 16-bit setup code. This way, they will not be overwritten by
kernel. Do you think this works.

Best Regards,
Huang Ying

Re: [PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol

[Andi Kleen]

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

> On Wed, 2007-10-17 at 10:25 +0200, Andi Kleen wrote:
> > "Huang, Ying" <ying.huang@intel.com> writes:
> > 
> > > Do you think it is a good idea to check the collision between setup data
> > > and memory area used during kernel boot through bootmem allocator?
> > 
> > You can't solve this through bootmem because x86-64 allocates memory
> > in several places before bootmem (using functions in e820.c) Right now
> > this is quite hackish with hard coded areas to avoid conflicts.  But I
> > recently had a need to allocate more memory that early too and changed
> > the code to a generic early reservation interface. With that it would
> > be relatively easy to reserve.
> 
> Can you tell me what that early reservation interface is? What I find in
> x86_64 that does early memory allocation is alloc_low_page, which gets
> non-conflict memory area through e820 map.

It's a new interface I only recently wrote:

ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/early-reserve

Then you can use early_reserve() and the e820 allocator will not touch
it.

> Because setup data is allocated by bootloader or kernel 16-bit setup
> code, and the e820 map is created there too, the memory area used by
> setup data can be made reserved memory area in e820 map by bootloader or
> kernel 16-bit setup code. This way, they will not be overwritten by
> kernel. Do you think this works.

It has a little of a chicken'n'egg problem because the e820 map will
be actually in the area you want to reserve. But it might work too.
Boot data is normally copied before other allocations in head64.c
If you do variable size boot data that might not work though.  And might
be a little fragile overall.

-Andi

Re: [PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol

[Huang, Ying]

On Wed, 2007-10-17 at 11:24 +0200, Andi Kleen wrote:
> > Can you tell me what that early reservation interface is? What I find in
> > x86_64 that does early memory allocation is alloc_low_page, which gets
> > non-conflict memory area through e820 map.
> 
> It's a new interface I only recently wrote:
> 
> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/early-reserve
> 
> Then you can use early_reserve() and the e820 allocator will not touch
> it.
> 
> > Because setup data is allocated by bootloader or kernel 16-bit setup
> > code, and the e820 map is created there too, the memory area used by
> > setup data can be made reserved memory area in e820 map by bootloader or
> > kernel 16-bit setup code. This way, they will not be overwritten by
> > kernel. Do you think this works.
> 
> It has a little of a chicken'n'egg problem because the e820 map will
> be actually in the area you want to reserve. But it might work too.
> Boot data is normally copied before other allocations in head64.c
> If you do variable size boot data that might not work though.  And might
> be a little fragile overall.

Although variable size boot data (such as setup data) can be reserved
via early_reserve or e820 map, they may conflict with hard-coded memory
area used by kernel. This means boot loader must know the hard-coded
memory area used by kernel.

Another possible solution is as follow:
1. Bootloader allocates memory for setup data. Just avoid the memory
area after kernel loaded address.
2. In the very early stage of kernel boot (head64.c). Copy all the setup
data to the memory area after _end. And reserve that memory area with
early_reserve (or bad_addr for old code).

In this solution, the only unsafe memory area for setup data from
bootloader is memory area after _end. And kernel can use hard coded
memory area without the risk of conflicting with setup data from
bootloader.

Do you think this solution is better?

Best Regards,
Huang Ying

Re: [PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol

[Eric W. Biederman]

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

> This patchset defines a 32-bit boot protocol for i386/x86_64 platform,
> adds an extensible boot parameter passing mechanism, export the boot
> parameters via sysfs.
>
> The patchset has been tested against 2.6.23-rc8-mm2 kernel on x86_64
> and i386.
>
> This patchset is based on the proposal of Peter Anvin.
>
>
> Known Issues:
>
> - Where is safe to place the linked list of setup_data?  Because the
>   length of the linked list of setup_data is variable, it can not be
>   copied into BSS segment of kernel as that of "zero page". We must
>   find a safe place for it, where it will not be overwritten by kernel
>   during booting up. The i386 kernel will overwrite some pages after
>   _end. The x86_64 kernel will overwrite some pages from 0x1000 on.

Well there actually is no reason to copy the current data into the
zero page.  We really should just leave it where it is until the
kernel has managed to bootstrap it's basic services.

As for the setup data can we please remove the pointers. And just
require the that the data items be appended one after each other
in memory.  Then we would just need a field where we could
report an offset to the binary data from where we loaded the
16bit code/data.  We could even specify the end by requiring
that we fill in setup_move_size or something of that nature.

Beyond that we should provide the bootloaders enough information to
know which information the kernel will overwrite before it consults
the e820 map and other indicators of what memory is free.

Eric

Re: [PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol

[Huang, Ying]

On Wed, 2007-10-17 at 03:38 -0600, Eric W. Biederman wrote:
> Well there actually is no reason to copy the current data into the
> zero page.  We really should just leave it where it is until the
> kernel has managed to bootstrap it's basic services.

I think it is safer to copy boot parameters to kernel BSS segment.
Because the kernel bootstrap process may overwrite the original memory
area of boot parameters.

> As for the setup data can we please remove the pointers. And just
> require the that the data items be appended one after each other
> in memory.  Then we would just need a field where we could
> report an offset to the binary data from where we loaded the
> 16bit code/data.  We could even specify the end by requiring
> that we fill in setup_move_size or something of that nature.

In this solution, we should also avoid conflict between the boot data
and kernel early bootstrap process. I think copy these boot data to some
place safe may be better. Such as memory area after _end.

> Beyond that we should provide the bootloaders enough information to
> know which information the kernel will overwrite before it consults
> the e820 map and other indicators of what memory is free.

There are several memory areas used by kernel bootstrap before e820 map
is consulted. You can refer to bad_addr for details. So I think it may
be not a stable/simple prototype to provide this information to
bootloader.

Best Regards,
Huang Ying