i386/x86_64 boot: 32-bit boot protocol
cover i386/x86_64 boot: 32-bit boot protocol
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
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
Quoted 45 lines · 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_64and 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 ofsetup_datais 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. Thex86_64kernel will overwrite some pages from0x1000on.- 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_dataand boot parameters for accessing during runtime.
- Export boot parameters via sysfs.v3:
- Move
hd0_infoandhd1_infoback 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.
Quoted 8 lines · Ying
Known Issues:
- Where is safe to place the linked list of
setup_data? Because the length of the linked list ofsetup_datais 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. Thex86_64kernel will overwrite some pages from0x1000on.
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
Quoted 2 lines · Ying
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
Quoted 11 lines · Andi Kleen
Quoted 2 lines · Ying
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
Quoted 13 lines · Ying
Quoted 11 lines · Andi Kleen
Quoted 2 lines · Ying
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.
Quoted 3 lines
Can you tell me what that early reservation interface is? What I find in
x86_64that does early memory allocation isalloc_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.
Quoted 5 lines
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
Quoted 17 lines · Andi Kleen
Quoted 3 lines
Can you tell me what that early reservation interface is? What I find in
x86_64that does early memory allocation isalloc_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.Quoted 5 lines
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.
Quoted 5 lines
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.cIf 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
Quoted 10 lines · 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_64and i386.This patchset is based on the proposal of Peter Anvin.
Quoted 8 lines
Known Issues:
- Where is safe to place the linked list of
setup_data? Because the length of the linked list ofsetup_datais 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. Thex86_64kernel will overwrite some pages from0x1000on.
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
Quoted 3 lines · Eric W. Biederman
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.
Quoted 6 lines
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_sizeor 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.
Quoted 3 lines
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