lkml.org 
[lkml]   [2018]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 0/3] x86: make rsdp address accessible via boot params
From
Date
On 10/10/2018 08:23, Ingo Molnar wrote:
>
> * Juergen Gross <jgross@suse.com> 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@gmail.com/

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

\
 
 \ /
  Last update: 2018-10-10 08:40    [W:0.110 / U:1.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site