|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [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: 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |