Re: [PATCH v5 0/3] x86: make rsdp address accessible via boot params

[Juergen Gross]

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:

https://lore.kernel.org/lkml/20180213163244.j2zuxyhs4kbfhwgj@xxxxxxxxx/

The scheme I have used in V5 of the series is the one you agreed to use
back then.

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
act accordingly.

The related grub2 patch series is under review right now.


Juergen