Re: [PATCH v2 00/12] treewide: break dependencies on x86's RM header

From: Sean Christopherson
Date: Wed Nov 27 2019 - 09:47:07 EST


On Wed, Nov 27, 2019 at 08:20:57AM +0100, Ingo Molnar wrote:
>
> * Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote:
>
> > x86's asm/realmode.h, which defines low level structures, variables and
> > helpers used to bring up APs during SMP boot, ends up getting included in
> > practically every nook and cranny of the kernel because the address used
> > by ACPI for resuming from S3 also happens to be stored in the real mode
> > header, and ACPI bleeds the dependency into its widely included headers.
> >
> > As a result, modifying realmode.h for even the most trivial change to the
> > boot code triggers a full kernel rebuild, which is frustrating to say the
> > least as it some of the most difficult code to get exactly right *and* is
> > also some of the most functionally isolated code in the kernel.
> >
> > To break the kernel's widespread dependency on realmode.h, add a wrapper
> > in the aforementioned ACPI S3 code to access the real mode header instead
> > of derefencing the header directly in asm/acpi.h and thereby exposing it
> > to the world via linux/acpi.h.
> >
> > v2:
> > - Rebased on tip/x86/cleanups, commit b74374fef924 ("x86/setup: Enhance
> > the comments").
> > - Use acpi_get_wakeup_address() as new function name. [Boris and Pavel]
> > - Capture acpi_get_wakeup_address() in a local address. [Pavel]
> > - Collect acks. I didn't add Rafael's acks on patches 11 and 12 due to
> > the above changes.
> > - Explicitly call out the removal of <asm/realmode.h> from <asm/acpi.h>
> > in patch 12. [Ingo]
> > - Remove superfluous Fixes: tags. [Ard]
>
> You didn't include every patch from v1 though, such us my fix to Quark:
>
> [PATCH] x86/platform/intel/quark: Explicitly include linux/io.h for virt_to_phys()
>
> I've applied that one too and your updated patches, and it's now all
> pushed out into tip:WIP.core/headers.

Sorry, it wasn't clear to me whether or not to include that one. Next
time I'll ask.