| Message ID | 20171207122821.30158-2-jgross@suse.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
* Juergen Gross <jgross@suse.com> wrote: > Xen PVH guests receive the address of the RSDP table from Xen. In order > to support booting a Xen PVH guest via grub2 using the standard x86 > boot entry we need a way fro grub2 to pass the RSDP address to the > kernel. > > For this purpose expand the struct setup_header to hold the physical > address of the RSDP address. Being zero means it isn't specified and > has to be located the legacy way (searching through low memory or > EBDA). s/fro /for pedantry: s/grub2 /Grub2 > Signed-off-by: Juergen Gross <jgross@suse.com> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> > --- > Documentation/x86/boot.txt | 19 +++++++++++++++++++ > arch/x86/boot/header.S | 6 +++++- > arch/x86/include/uapi/asm/bootparam.h | 1 + > 3 files changed, 25 insertions(+), 1 deletion(-) > > diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt > index 5e9b826b5f62..a33c224797e4 100644 > --- a/Documentation/x86/boot.txt > +++ b/Documentation/x86/boot.txt > @@ -61,6 +61,13 @@ Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields > to struct boot_params for loading bzImage and ramdisk > above 4G in 64bit. > > +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 The changelog should I think declare that we add documentation for the 2.13 protocol iteration as well. Also, please use a consistent spelling of '32-bit' and '64-bit' in the same sentence! > +Field name: acpi_rsdp_addr > +Type: write > +Offset/size: 0x268/8 > +Protocol: 2.14+ > + > + This field can be set by the boot loader to tell the kernel the > + physical address of the ACPI RSDP table. > + > + A value of 0 indicates the kernel should fall back to the standard > + methods to locate the RSDP (search in EBDA/low memory). That's not the only method used: the ACPI RSDP address can also be discovered via efi.rsdp20 and efi.rsdp, both of which appear to be 32-bit values. > **** THE IMAGE CHECKSUM > > diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S > index 850b8762e889..e7184127f309 100644 > --- a/arch/x86/boot/header.S > +++ b/arch/x86/boot/header.S > @@ -300,7 +300,7 @@ _start: > # Part 2 of the header, from the old setup.S > > .ascii "HdrS" # header signature > - .word 0x020d # header version number (>= 0x0105) > + .word 0x020e # header version number (>= 0x0105) > # or else old loadlin-1.5 will fail) > .globl realmode_swtch > realmode_swtch: .word 0, 0 # default_switch, SETUPSEG > @@ -558,6 +558,10 @@ pref_address: .quad LOAD_PHYSICAL_ADDR # preferred load addr > init_size: .long INIT_SIZE # kernel initialization size > handover_offset: .long 0 # Filled in by build.c > > +acpi_rsdp_addr: .quad 0 # 64-bit physical pointer to > + # ACPI RSDP table, added with > + # version 2.14 s/pointer to ACPI RSDP table /pointer to the ACPI RSDP table Also, a more fundamental question: why doesn't Xen use EFI to hand over hardware configuration details? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> On 08.12.17 at 08:16, <mingo@kernel.org> wrote: > Also, a more fundamental question: why doesn't Xen use EFI to hand over > hardware configuration details? Iirc the main purpose of the change here is to allow booting PVH (guest or Dom0) with Grub2 in the middle. PVH, at least for the time being, is something that gets away without any firmware (and I'm pretty certain this is going to remain that way for Dom0). ACPI tables are being built by the tool stack (guest) or hypervisor (Dom0). Hence there simply isn't any EFI which could be used to propagate such information. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Jan Beulich <JBeulich@suse.com> wrote: > >>> On 08.12.17 at 08:16, <mingo@kernel.org> wrote: > > Also, a more fundamental question: why doesn't Xen use EFI to hand over > > hardware configuration details? > > Iirc the main purpose of the change here is to allow booting PVH > (guest or Dom0) with Grub2 in the middle. PVH, at least for the > time being, is something that gets away without any firmware > (and I'm pretty certain this is going to remain that way for Dom0). > ACPI tables are being built by the tool stack (guest) or hypervisor > (Dom0). Hence there simply isn't any EFI which could be used to > propagate such information. Ok, that's fair enough. If hpa (or someone else) doesn't object to the boot protocol extension this approach looks good to me in principle. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/12/17 08:16, Ingo Molnar wrote: > > * Juergen Gross <jgross@suse.com> wrote: > >> Xen PVH guests receive the address of the RSDP table from Xen. In order >> to support booting a Xen PVH guest via grub2 using the standard x86 >> boot entry we need a way fro grub2 to pass the RSDP address to the >> kernel. >> >> For this purpose expand the struct setup_header to hold the physical >> address of the RSDP address. Being zero means it isn't specified and >> has to be located the legacy way (searching through low memory or >> EBDA). > > s/fro > /for > > pedantry: > > s/grub2 > /Grub2 Okay. > >> Signed-off-by: Juergen Gross <jgross@suse.com> >> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> >> --- >> Documentation/x86/boot.txt | 19 +++++++++++++++++++ >> arch/x86/boot/header.S | 6 +++++- >> arch/x86/include/uapi/asm/bootparam.h | 1 + >> 3 files changed, 25 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt >> index 5e9b826b5f62..a33c224797e4 100644 >> --- a/Documentation/x86/boot.txt >> +++ b/Documentation/x86/boot.txt >> @@ -61,6 +61,13 @@ Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields >> to struct boot_params for loading bzImage and ramdisk >> above 4G in 64bit. >> >> +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 > > The changelog should I think declare that we add documentation for the 2.13 > protocol iteration as well. > > Also, please use a consistent spelling of '32-bit' and '64-bit' in the same > sentence! Okay. > >> +Field name: acpi_rsdp_addr >> +Type: write >> +Offset/size: 0x268/8 >> +Protocol: 2.14+ >> + >> + This field can be set by the boot loader to tell the kernel the >> + physical address of the ACPI RSDP table. >> + >> + A value of 0 indicates the kernel should fall back to the standard >> + methods to locate the RSDP (search in EBDA/low memory). > > That's not the only method used: the ACPI RSDP address can also be discovered via > efi.rsdp20 and efi.rsdp, both of which appear to be 32-bit values. Sure, but this is valid for booting via EFI only. > >> **** THE IMAGE CHECKSUM >> >> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S >> index 850b8762e889..e7184127f309 100644 >> --- a/arch/x86/boot/header.S >> +++ b/arch/x86/boot/header.S >> @@ -300,7 +300,7 @@ _start: >> # Part 2 of the header, from the old setup.S >> >> .ascii "HdrS" # header signature >> - .word 0x020d # header version number (>= 0x0105) >> + .word 0x020e # header version number (>= 0x0105) >> # or else old loadlin-1.5 will fail) >> .globl realmode_swtch >> realmode_swtch: .word 0, 0 # default_switch, SETUPSEG >> @@ -558,6 +558,10 @@ pref_address: .quad LOAD_PHYSICAL_ADDR # preferred load addr >> init_size: .long INIT_SIZE # kernel initialization size >> handover_offset: .long 0 # Filled in by build.c >> >> +acpi_rsdp_addr: .quad 0 # 64-bit physical pointer to >> + # ACPI RSDP table, added with >> + # version 2.14 > > s/pointer to ACPI RSDP table > /pointer to the ACPI RSDP table Okay. > > Also, a more fundamental question: why doesn't Xen use EFI to hand over hardware > configuration details? I think Jan has answered this question quite well. Juergen -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Juergen Gross <jgross@suse.com> wrote: > >> +Offset/size: 0x268/8 > >> +Protocol: 2.14+ > >> + > >> + This field can be set by the boot loader to tell the kernel the > >> + physical address of the ACPI RSDP table. > >> + > >> + A value of 0 indicates the kernel should fall back to the standard > >> + methods to locate the RSDP (search in EBDA/low memory). > > > > That's not the only method used: the ACPI RSDP address can also be discovered via > > efi.rsdp20 and efi.rsdp, both of which appear to be 32-bit values. > > Sure, but this is valid for booting via EFI only. Yeah, so what I tried to say is that the description as written is not fully correct and triggered my pedantry: + A value of 0 indicates the kernel should fall back to the standard + methods to locate the RSDP (search in EBDA/low memory). To make it correct we need to either write less: + A value of 0 indicates the kernel should fall back to the standard + methods to locate the RSDP. or write more and make it open ended so it doesn't have to be extended with every method of getting the RSDP that might be added in the future: + A value of 0 indicates the kernel should fall back to the standard + methods to locate the RSDP (search in EBDA/low memory, get it from + EFI if present, etc.). ... or so? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/12/17 09:48, Ingo Molnar wrote: > > * Juergen Gross <jgross@suse.com> wrote: > >>>> +Offset/size: 0x268/8 >>>> +Protocol: 2.14+ >>>> + >>>> + This field can be set by the boot loader to tell the kernel the >>>> + physical address of the ACPI RSDP table. >>>> + >>>> + A value of 0 indicates the kernel should fall back to the standard >>>> + methods to locate the RSDP (search in EBDA/low memory). >>> >>> That's not the only method used: the ACPI RSDP address can also be discovered via >>> efi.rsdp20 and efi.rsdp, both of which appear to be 32-bit values. >> >> Sure, but this is valid for booting via EFI only. > > Yeah, so what I tried to say is that the description as written is not fully > correct and triggered my pedantry: > > + A value of 0 indicates the kernel should fall back to the standard > + methods to locate the RSDP (search in EBDA/low memory). > > To make it correct we need to either write less: > > + A value of 0 indicates the kernel should fall back to the standard > + methods to locate the RSDP. > > or write more and make it open ended so it doesn't have to be extended with every > method of getting the RSDP that might be added in the future: > > + A value of 0 indicates the kernel should fall back to the standard > + methods to locate the RSDP (search in EBDA/low memory, get it from > + EFI if present, etc.). > > ... or so? Aah, okay. I got your remark wrong then. I think I'll go with the shorter variant. Juergen -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt index 5e9b826b5f62..a33c224797e4 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt @@ -61,6 +61,13 @@ Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields to struct boot_params for loading bzImage and ramdisk above 4G in 64bit. +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 (Kernel 4.16) Added acpi_rsdp_addr holding the physical + address of the ACPI RSDP table. + **** MEMORY LAYOUT The traditional memory map for the kernel loader, used for Image or @@ -197,6 +204,7 @@ Offset Proto Name Meaning 0258/8 2.10+ pref_address Preferred 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/8 2.14+ acpi_rsdp_addr Physical address of RSDP table (1) For backwards compatibility, if the setup_sects field contains 0, the real value is 4. @@ -744,6 +752,17 @@ Offset/size: 0x264/4 See EFI HANDOVER PROTOCOL below for more details. +Field name: acpi_rsdp_addr +Type: write +Offset/size: 0x268/8 +Protocol: 2.14+ + + This field can be set by the boot loader to tell the kernel the + physical address of the ACPI RSDP table. + + A value of 0 indicates the kernel should fall back to the standard + methods to locate the RSDP (search in EBDA/low memory). + **** THE IMAGE CHECKSUM diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 850b8762e889..e7184127f309 100644 --- a/arch/x86/boot/header.S +++ b/arch/x86/boot/header.S @@ -300,7 +300,7 @@ _start: # Part 2 of the header, from the old setup.S .ascii "HdrS" # header signature - .word 0x020d # header version number (>= 0x0105) + .word 0x020e # header version number (>= 0x0105) # or else old loadlin-1.5 will fail) .globl realmode_swtch realmode_swtch: .word 0, 0 # default_switch, SETUPSEG @@ -558,6 +558,10 @@ pref_address: .quad LOAD_PHYSICAL_ADDR # preferred load addr init_size: .long INIT_SIZE # kernel initialization size handover_offset: .long 0 # Filled in by build.c +acpi_rsdp_addr: .quad 0 # 64-bit physical pointer to + # ACPI RSDP table, added with + # version 2.14 + # End of setup header ##################################################### .section ".entrytext", "ax" diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h index afdd5ae0fcc4..5742e433e93e 100644 --- a/arch/x86/include/uapi/asm/bootparam.h +++ b/arch/x86/include/uapi/asm/bootparam.h @@ -85,6 +85,7 @@ struct setup_header { __u64 pref_address; __u32 init_size; __u32 handover_offset; + __u64 acpi_rsdp_addr; } __attribute__((packed)); struct sys_desc_table {