Re: [PATCH v5 0/3] x86: make rsdp address accessible via boot params
- Date: Wed, 10 Oct 2018 08:39:42 +0200
- From: Juergen Gross <jgross@xxxxxxxx>
- Subject: Re: [PATCH v5 0/3] x86: make rsdp address accessible via boot params
On 10/10/2018 08:23, Ingo Molnar wrote:
> * Juergen Gross <jgross@xxxxxxxx> wrote:
>> In the non-EFI boot path the ACPI RSDP table is currently found via
>> either EBDA or by searching through low memory for the RSDP magic.
>> This requires the RSDP to be located in the first 1MB of physical
>> memory. Xen PVH guests, however, get the RSDP address via the start of
>> day information block.
>> In order to support an arbitrary RSDP address this patch series adds
>> the physical address of the RSDP to the boot params structure filled
>> by the boot loader.
>> Juergen Gross (3):
>> x86/xen: fix boot loader version reported for pvh guests
>> x86/boot: add acpi rsdp address to setup_header
>> x86/acpi: take rsdp address for boot params if available
>> Documentation/x86/boot.txt | 32 +++++++++++++++++++++++++++++++-
>> arch/x86/boot/header.S | 6 +++++-
>> arch/x86/include/asm/acpi.h | 7 +++++++
>> arch/x86/include/asm/x86_init.h | 2 ++
>> arch/x86/include/uapi/asm/bootparam.h | 4 ++++
>> arch/x86/kernel/acpi/boot.c | 6 ++++++
>> arch/x86/kernel/head32.c | 1 +
>> arch/x86/kernel/head64.c | 2 ++
>> arch/x86/kernel/setup.c | 17 +++++++++++++++++
>> arch/x86/kernel/x86_init.c | 3 +--
>> arch/x86/xen/enlighten_pvh.c | 2 +-
>> 11 files changed, 77 insertions(+), 5 deletions(-)
> I have some vague memories of an older variant of this feature breaking stuff and resulting in
> me involuntarily participating in an overly long bisection session.
> If that memory is right and I'm not confusing it with some other patchset, could you please
> provide some more context, what that old problem was, how it was resolved, whether it is
> expected to trigger on any machines, etc., to create some warm fuzzy feelings about this
> patch-set and to reduce my bisectofobia? ;-)
You can just dive into the discussion we had back in February:
The scheme I have used in V5 of the series is the one you agreed to use
A quick summary of the problem you mentioned:
There are some downstream variants of grub2 with a patch breaking the
boot protocol by writing garbage past the end of setup_header. Adding
a new field at the end of setup_header (here: rsdp_address) resulted in
those grub2 variants clobbering the preset value of 0.
The solution is to let grub2 report back the used boot protocol version
with setting a flag "I am reporting back my version". The kernel now is
capable to know which fields of setup_header are known to grub2 and can
The related grub2 patch series is under review right now.