Re: [Xen-devel] [PATCH v3 1/3] x86/boot: Introduce the kernel_info
> >>> +be prefixed with header/magic and its size, e.g.: > >>> + > >>> + kernel_info: > >>> + .ascii "LToP" /* Header, Linux top (structure). */ > >>> + .long kernel_info_var_len_data - kernel_info > >>> + .long kernel_info_end - kernel_info > >>> + .long 0x01234567 /* Some fixed size data for the > >>> bootloaders. */ > >>> + kernel_info_var_len_data: > >>> + example_struct: /* Some variable size data for the > >>> bootloaders. */ > >>> + .ascii "EsTT" /* Header/Magic. */ > >>> + .long example_struct_end - example_struct > >>> + .ascii "Struct" > >>> + .long 0x89012345 > >>> + example_struct_end: > >>> + example_strings:/* Some variable size data for the > >>> bootloaders. */ > >>> + .ascii "EsTs" /* Header/Magic. */ > >> > >> Where do the Magic values "EsTT" and "EsTs" come from? > >> where are they defined? > > > > EsTT == Example STrucT > > EsTs == Example STringS > > > > Anyway, it can be anything which does not collide with existing variable > > length data magics. There are none right now. So, it can be anything. > > Maybe I should add something saying that. > > Yes, please. Or make it very clear they are examples, says "1234" or "ABCD" or such. > > thanks. > -- > ~Randy ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] x86/boot: Introduce the kernel_info
On 10/10/19 2:43 AM, Daniel Kiper wrote: > On Wed, Oct 09, 2019 at 05:43:31PM -0700, Randy Dunlap wrote: >> Hi, >> >> Questions and comments below... >> Thanks. >> >> On 10/9/19 3:53 AM, Daniel Kiper wrote: >> >>> Suggested-by: H. Peter Anvin >>> Signed-off-by: Daniel Kiper >>> Reviewed-by: Konrad Rzeszutek Wilk >>> Reviewed-by: Ross Philipson >>> --- >> >>> --- >>> Documentation/x86/boot.rst | 121 >>> + >>> arch/x86/boot/Makefile | 2 +- >>> arch/x86/boot/compressed/Makefile | 4 +- >>> arch/x86/boot/compressed/kernel_info.S | 17 + >>> arch/x86/boot/header.S | 1 + >>> arch/x86/boot/tools/build.c| 5 ++ >>> arch/x86/include/uapi/asm/bootparam.h | 1 + >>> 7 files changed, 148 insertions(+), 3 deletions(-) >>> create mode 100644 arch/x86/boot/compressed/kernel_info.S >>> >>> diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst >>> index 08a2f100c0e6..d5323a39f5e3 100644 >>> --- a/Documentation/x86/boot.rst >>> +++ b/Documentation/x86/boot.rst >>> @@ -68,8 +68,25 @@ Protocol 2.12(Kernel 3.8) Added the xloadflags field >>> and extension fields >>> Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in >>> xloadflags to support booting a 64-bit kernel from 32-bit >>> EFI >>> + >>> +Protocol 2.14: BURNT BY INCORRECT COMMIT >>> ae7e1238e68f2a472a125673ab506d49158c1889 >>> + (x86/boot: Add ACPI RSDP address to setup_header) >>> + DO NOT USE!!! ASSUME SAME AS 2.13. >>> + >>> +Protocol 2.15: (Kernel 5.5) Added the kernel_info. >>> = >>> >>> >>> +.. note:: >>> + The protocol version number should be changed only if the setup header >>> + is changed. There is no need to update the version number if >>> boot_params >>> + or kernel_info are changed. Additionally, it is recommended to use >>> + xloadflags (in this case the protocol version number should not be >>> + updated either) or kernel_info to communicate supported Linux kernel >>> + features to the boot loader. Due to very limited space available in >>> + the original setup header every update to it should be considered >>> + with great care. Starting from the protocol 2.15 the primary way to >>> + communicate things to the boot loader is the kernel_info. >>> + >>> >>> Memory Layout >>> = >>> @@ -207,6 +224,7 @@ Offset/Size Proto Name >>> Meaning >>> 0258/8 2.10+ pref_addressPreferred >>> loading address >>> 0260/4 2.10+ init_size Linear memory >>> required during initialization >>> 0264/4 2.11+ handover_offset Offset of >>> handover entry point >>> +0268/4 2.15+ kernel_info_offset Offset of the >>> kernel_info >>> ==== >>> >>> >>> .. note:: >>> @@ -855,6 +873,109 @@ Offset/size: 0x264/4 >>> >>>See EFI HANDOVER PROTOCOL below for more details. >>> >>> + == >>> +Field name:kernel_info_offset >>> +Type: read >>> +Offset/size: 0x268/4 >>> +Protocol: 2.15+ >>> + == >>> + >>> + This field is the offset from the beginning of the kernel image to the >>> + kernel_info. It is embedded in the Linux image in the uncompressed >> ^^ >>What does It refer to, please? > > s/It/The kernel_info structure/ Is it better? Yes. >>> + protected mode region. >>> + >>> + >>> +The kernel_info >>> +=== >>> + >>> +The relationships between the headers are analogous to the various data >>> +sections: >>> + >>> + setup_header = .data >>> + boot_params/setup_data = .bss >>> + >>> +What is missing from the above list? That's right: >>> + >>> + kernel_info = .rodata >>> + >>> +We have been (ab)using .data for things that could go into .rodata or .bss >>> for >>> +a long time, for lack of alternatives and -- especially early on -- >>> inertia. >>> +Also, the BIOS stub is responsible for creating boot_params, so it isn't >>> +available to a BIOS-based loader (setup_data is, though). >>> + >>> +setup_header is permanently limited to 144 bytes due to the reach of the >>> +2-byte jump field, which doubles as a length field for the structure, >>> combined >>> +with the size of the "hole" in struct boot_params that a protected-mode >>> loader >>> +or the BIOS stub has to copy it into. It is currently 119 bytes long, which >>> +leaves us with 25 very precious bytes. This isn't something that can be >>> fixed >>> +without revising the boot protocol entirely, breaking backwards >>> compatibility. >>> + >>> +boot_params proper is limited to 4096
Re: [Xen-devel] [PATCH v3 1/3] x86/boot: Introduce the kernel_info
On Wed, Oct 09, 2019 at 05:43:31PM -0700, Randy Dunlap wrote: > Hi, > > Questions and comments below... > Thanks. > > On 10/9/19 3:53 AM, Daniel Kiper wrote: > > > Suggested-by: H. Peter Anvin > > Signed-off-by: Daniel Kiper > > Reviewed-by: Konrad Rzeszutek Wilk > > Reviewed-by: Ross Philipson > > --- > > > --- > > Documentation/x86/boot.rst | 121 > > + > > arch/x86/boot/Makefile | 2 +- > > arch/x86/boot/compressed/Makefile | 4 +- > > arch/x86/boot/compressed/kernel_info.S | 17 + > > arch/x86/boot/header.S | 1 + > > arch/x86/boot/tools/build.c| 5 ++ > > arch/x86/include/uapi/asm/bootparam.h | 1 + > > 7 files changed, 148 insertions(+), 3 deletions(-) > > create mode 100644 arch/x86/boot/compressed/kernel_info.S > > > > diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst > > index 08a2f100c0e6..d5323a39f5e3 100644 > > --- a/Documentation/x86/boot.rst > > +++ b/Documentation/x86/boot.rst > > @@ -68,8 +68,25 @@ Protocol 2.12(Kernel 3.8) Added the xloadflags field > > and extension fields > > Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in > > xloadflags to support booting a 64-bit kernel from 32-bit > > EFI > > + > > +Protocol 2.14: BURNT BY INCORRECT COMMIT > > ae7e1238e68f2a472a125673ab506d49158c1889 > > + (x86/boot: Add ACPI RSDP address to setup_header) > > + DO NOT USE!!! ASSUME SAME AS 2.13. > > + > > +Protocol 2.15: (Kernel 5.5) Added the kernel_info. > > = > > > > > > +.. note:: > > + The protocol version number should be changed only if the setup header > > + is changed. There is no need to update the version number if > > boot_params > > + or kernel_info are changed. Additionally, it is recommended to use > > + xloadflags (in this case the protocol version number should not be > > + updated either) or kernel_info to communicate supported Linux kernel > > + features to the boot loader. Due to very limited space available in > > + the original setup header every update to it should be considered > > + with great care. Starting from the protocol 2.15 the primary way to > > + communicate things to the boot loader is the kernel_info. > > + > > > > Memory Layout > > = > > @@ -207,6 +224,7 @@ Offset/Size Proto Name > > Meaning > > 0258/8 2.10+ pref_addressPreferred > > loading address > > 0260/4 2.10+ init_size Linear memory > > required during initialization > > 0264/4 2.11+ handover_offset Offset of > > handover entry point > > +0268/4 2.15+ kernel_info_offset Offset of the > > kernel_info > > ==== > > > > > > .. note:: > > @@ -855,6 +873,109 @@ Offset/size: 0x264/4 > > > >See EFI HANDOVER PROTOCOL below for more details. > > > > + == > > +Field name:kernel_info_offset > > +Type: read > > +Offset/size: 0x268/4 > > +Protocol: 2.15+ > > + == > > + > > + This field is the offset from the beginning of the kernel image to the > > + kernel_info. It is embedded in the Linux image in the uncompressed > ^^ >What does It refer to, please? s/It/The kernel_info structure/ Is it better? > > + protected mode region. > > + > > + > > +The kernel_info > > +=== > > + > > +The relationships between the headers are analogous to the various data > > +sections: > > + > > + setup_header = .data > > + boot_params/setup_data = .bss > > + > > +What is missing from the above list? That's right: > > + > > + kernel_info = .rodata > > + > > +We have been (ab)using .data for things that could go into .rodata or .bss > > for > > +a long time, for lack of alternatives and -- especially early on -- > > inertia. > > +Also, the BIOS stub is responsible for creating boot_params, so it isn't > > +available to a BIOS-based loader (setup_data is, though). > > + > > +setup_header is permanently limited to 144 bytes due to the reach of the > > +2-byte jump field, which doubles as a length field for the structure, > > combined > > +with the size of the "hole" in struct boot_params that a protected-mode > > loader > > +or the BIOS stub has to copy it into. It is currently 119 bytes long, which > > +leaves us with 25 very precious bytes. This isn't something that can be > > fixed > > +without revising the boot protocol entirely, breaking backwards > > compatibility. > > + > > +boot_params proper is limited to 4096 bytes, but can be arbitrarily > > extended > > +by adding
Re: [Xen-devel] [PATCH v3 1/3] x86/boot: Introduce the kernel_info
Hi, Questions and comments below... Thanks. On 10/9/19 3:53 AM, Daniel Kiper wrote: > Suggested-by: H. Peter Anvin > Signed-off-by: Daniel Kiper > Reviewed-by: Konrad Rzeszutek Wilk > Reviewed-by: Ross Philipson > --- > --- > Documentation/x86/boot.rst | 121 > + > arch/x86/boot/Makefile | 2 +- > arch/x86/boot/compressed/Makefile | 4 +- > arch/x86/boot/compressed/kernel_info.S | 17 + > arch/x86/boot/header.S | 1 + > arch/x86/boot/tools/build.c| 5 ++ > arch/x86/include/uapi/asm/bootparam.h | 1 + > 7 files changed, 148 insertions(+), 3 deletions(-) > create mode 100644 arch/x86/boot/compressed/kernel_info.S > > diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst > index 08a2f100c0e6..d5323a39f5e3 100644 > --- a/Documentation/x86/boot.rst > +++ b/Documentation/x86/boot.rst > @@ -68,8 +68,25 @@ Protocol 2.12 (Kernel 3.8) Added the xloadflags field > and extension fields > Protocol 2.13(Kernel 3.14) Support 32- and 64-bit flags being set in > xloadflags to support booting a 64-bit kernel from 32-bit > EFI > + > +Protocol 2.14: BURNT BY INCORRECT COMMIT > ae7e1238e68f2a472a125673ab506d49158c1889 > + (x86/boot: Add ACPI RSDP address to setup_header) > + DO NOT USE!!! ASSUME SAME AS 2.13. > + > +Protocol 2.15: (Kernel 5.5) Added the kernel_info. > = > > > +.. note:: > + The protocol version number should be changed only if the setup header > + is changed. There is no need to update the version number if boot_params > + or kernel_info are changed. Additionally, it is recommended to use > + xloadflags (in this case the protocol version number should not be > + updated either) or kernel_info to communicate supported Linux kernel > + features to the boot loader. Due to very limited space available in > + the original setup header every update to it should be considered > + with great care. Starting from the protocol 2.15 the primary way to > + communicate things to the boot loader is the kernel_info. > + > > Memory Layout > = > @@ -207,6 +224,7 @@ Offset/Size Proto Name > Meaning > 0258/8 2.10+ pref_addressPreferred > loading address > 0260/4 2.10+ init_size Linear memory > required during initialization > 0264/4 2.11+ handover_offset Offset of > handover entry point > +0268/4 2.15+ kernel_info_offset Offset of the > kernel_info > === = > > > .. note:: > @@ -855,6 +873,109 @@ Offset/size:0x264/4 > >See EFI HANDOVER PROTOCOL below for more details. > > + == > +Field name: kernel_info_offset > +Type:read > +Offset/size: 0x268/4 > +Protocol:2.15+ > + == > + > + This field is the offset from the beginning of the kernel image to the > + kernel_info. It is embedded in the Linux image in the uncompressed ^^ What does It refer to, please? > + protected mode region. > + > + > +The kernel_info > +=== > + > +The relationships between the headers are analogous to the various data > +sections: > + > + setup_header = .data > + boot_params/setup_data = .bss > + > +What is missing from the above list? That's right: > + > + kernel_info = .rodata > + > +We have been (ab)using .data for things that could go into .rodata or .bss > for > +a long time, for lack of alternatives and -- especially early on -- inertia. > +Also, the BIOS stub is responsible for creating boot_params, so it isn't > +available to a BIOS-based loader (setup_data is, though). > + > +setup_header is permanently limited to 144 bytes due to the reach of the > +2-byte jump field, which doubles as a length field for the structure, > combined > +with the size of the "hole" in struct boot_params that a protected-mode > loader > +or the BIOS stub has to copy it into. It is currently 119 bytes long, which > +leaves us with 25 very precious bytes. This isn't something that can be fixed > +without revising the boot protocol entirely, breaking backwards > compatibility. > + > +boot_params proper is limited to 4096 bytes, but can be arbitrarily extended > +by adding setup_data entries. It cannot be used to communicate properties of > +the kernel image, because it is .bss and has no image-provided content. > + > +kernel_info solves this by providing an extensible place for information > about > +the kernel image. It is readonly, because the kernel cannot rely on a > +bootloader copying its contents anywhere, but that
[Xen-devel] [PATCH v3 1/3] x86/boot: Introduce the kernel_info
The relationships between the headers are analogous to the various data sections: setup_header = .data boot_params/setup_data = .bss What is missing from the above list? That's right: kernel_info = .rodata We have been (ab)using .data for things that could go into .rodata or .bss for a long time, for lack of alternatives and -- especially early on -- inertia. Also, the BIOS stub is responsible for creating boot_params, so it isn't available to a BIOS-based loader (setup_data is, though). setup_header is permanently limited to 144 bytes due to the reach of the 2-byte jump field, which doubles as a length field for the structure, combined with the size of the "hole" in struct boot_params that a protected-mode loader or the BIOS stub has to copy it into. It is currently 119 bytes long, which leaves us with 25 very precious bytes. This isn't something that can be fixed without revising the boot protocol entirely, breaking backwards compatibility. boot_params proper is limited to 4096 bytes, but can be arbitrarily extended by adding setup_data entries. It cannot be used to communicate properties of the kernel image, because it is .bss and has no image-provided content. kernel_info solves this by providing an extensible place for information about the kernel image. It is readonly, because the kernel cannot rely on a bootloader copying its contents anywhere, but that is OK; if it becomes necessary it can still contain data items that an enabled bootloader would be expected to copy into a setup_data chunk. This patch does not bump setup_header version in arch/x86/boot/header.S because it will be followed by additional changes coming into the Linux/x86 boot protocol. Suggested-by: H. Peter Anvin Signed-off-by: Daniel Kiper Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Ross Philipson --- v3 - suggestions/fixes: - split kernel_info data into fixed and variable sized regions, (suggested by H. Peter Anvin), - change kernel_info.header value to "LToP" (0x506f544c), (suggested by H. Peter Anvin), - improve the comments, - improve the documentation. v2 - suggestions/fixes: - rename setup_header2 to kernel_info, (suggested by H. Peter Anvin), - change kernel_info.header value to "InfO" (0x4f666e49), - new kernel_info description in Documentation/x86/boot.rst, (suggested by H. Peter Anvin), - drop kernel_info_offset_update() as an overkill and update kernel_info offset directly from main(), (suggested by Eric Snowberg), - new commit message (suggested by H. Peter Anvin), - fix some commit message misspellings (suggested by Eric Snowberg). --- Documentation/x86/boot.rst | 121 + arch/x86/boot/Makefile | 2 +- arch/x86/boot/compressed/Makefile | 4 +- arch/x86/boot/compressed/kernel_info.S | 17 + arch/x86/boot/header.S | 1 + arch/x86/boot/tools/build.c| 5 ++ arch/x86/include/uapi/asm/bootparam.h | 1 + 7 files changed, 148 insertions(+), 3 deletions(-) create mode 100644 arch/x86/boot/compressed/kernel_info.S diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst index 08a2f100c0e6..d5323a39f5e3 100644 --- a/Documentation/x86/boot.rst +++ b/Documentation/x86/boot.rst @@ -68,8 +68,25 @@ Protocol 2.12(Kernel 3.8) Added the xloadflags field and extension fields Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in xloadflags to support booting a 64-bit kernel from 32-bit EFI + +Protocol 2.14: BURNT BY INCORRECT COMMIT ae7e1238e68f2a472a125673ab506d49158c1889 + (x86/boot: Add ACPI RSDP address to setup_header) + DO NOT USE!!! ASSUME SAME AS 2.13. + +Protocol 2.15: (Kernel 5.5) Added the kernel_info. = +.. note:: + The protocol version number should be changed only if the setup header + is changed. There is no need to update the version number if boot_params + or kernel_info are changed. Additionally, it is recommended to use + xloadflags (in this case the protocol version number should not be + updated either) or kernel_info to communicate supported Linux kernel + features to the boot loader. Due to very limited space available in + the original setup header every update to it should be considered + with great care. Starting from the protocol 2.15 the primary way to + communicate things to the boot loader is the kernel_info. + Memory Layout = @@ -207,6 +224,7 @@ Offset/Size Proto NameMeaning 0258/8 2.10+ pref_addressPreferred loading address 0260/4 2.10+ init_size Linear memory required during initialization 0264/4 2.11+ handover_offset Offset of handover entry point +0268/4
