All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: David Hildenbrand <david@redhat.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	George Kennedy <george.kennedy@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	x86 Maintainers <x86@kernel.org>,
	Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH] ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade()
Date: Wed, 14 Apr 2021 12:48:43 +0200	[thread overview]
Message-ID: <CAJZ5v0g7Lm+eA=6C04f7xCdhKrE8cQxU6rSP9zxf0POpJDuDGg@mail.gmail.com> (raw)
In-Reply-To: <YHakFzNYBS6YLpPi@linux.ibm.com>

On Wed, Apr 14, 2021 at 10:13 AM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> On Wed, Apr 14, 2021 at 09:42:01AM +0200, David Hildenbrand wrote:
> > On 13.04.21 19:53, Rafael J. Wysocki wrote:
> > > On Tue, Apr 13, 2021 at 7:43 PM David Hildenbrand <david@redhat.com> wrote:
> > > >
> > > > On 13.04.21 16:01, Rafael J. Wysocki wrote:
> > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > >
> > > > > Commit 1a1c130ab757 ("ACPI: tables: x86: Reserve memory occupied by
> > > > > ACPI tables") attempted to address an issue with reserving the memory
> > > > > occupied by ACPI tables, but it broke the initrd-based table override
> > > > > mechanism relied on by multiple users.
> > > > >
> > > > > To restore the initrd-based ACPI table override functionality, move
> > > > > the acpi_boot_table_init() invocation in setup_arch() on x86 after
> > > > > the acpi_table_upgrade() one.
> > > > >
> > > > > Fixes: 1a1c130ab757 ("ACPI: tables: x86: Reserve memory occupied by ACPI tables")
> > > > > Reported-by: Hans de Goede <hdegoede@redhat.com>
> > > > > Tested-by: Hans de Goede <hdegoede@redhat.com>
> > > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > > ---
> > > > >
> > > > > George, can you please check if this reintroduces the issue addressed by
> > > > > the above commit for you?
> > > > >
> > > > > ---
> > > > >    arch/x86/kernel/setup.c |    5 ++---
> > > > >    1 file changed, 2 insertions(+), 3 deletions(-)
> > > > >
> > > > > Index: linux-pm/arch/x86/kernel/setup.c
> > > > > ===================================================================
> > > > > --- linux-pm.orig/arch/x86/kernel/setup.c
> > > > > +++ linux-pm/arch/x86/kernel/setup.c
> > > > > @@ -1045,9 +1045,6 @@ void __init setup_arch(char **cmdline_p)
> > > > >
> > > > >        cleanup_highmap();
> > > > >
> > > > > -     /* Look for ACPI tables and reserve memory occupied by them. */
> > > > > -     acpi_boot_table_init();
> > > > > -
> > > > >        memblock_set_current_limit(ISA_END_ADDRESS);
> > > > >        e820__memblock_setup();
> > > > >
> > > > > @@ -1132,6 +1129,8 @@ void __init setup_arch(char **cmdline_p)
> > > > >        reserve_initrd();
> > > > >
> > > > >        acpi_table_upgrade();
> > > > > +     /* Look for ACPI tables and reserve memory occupied by them. */
> > > > > +     acpi_boot_table_init();
> > > > >
> > > > >        vsmp_init();
> > > >
> > > > This is fairly late; especially, it's after actual allocations -- see
> > > > e820__memblock_alloc_reserved_mpc_new().
> > > >
> > > > Can't the table upgrade mechanism fix up when adjusting something?
> > >
> > > Not at this point of the cycle I'm afraid.
> > >
> > > > Some details on what actually breaks would be helpful.
> > >
> > > Generally speaking, the table overrides that come from the initrd are
> > > not taken into account if acpi_boot_table_init() runs before
> > > acpi_table_upgrade() and the latter cannot run before
> > > reserve_initrd().
> >
> > I see. (looking at Documentation/acpi/initrd_table_override.txt I understand
> > what acpi table overrides are for :) )
> >
> > >
> > > Honestly, I'm not sure how much effort it would take to untangle this ATM.
> >
> > Also true; ideally, we wouldn't have any allocations (find+reserve) before
> > ordinary reservations are done.
> >
> > However, I have no idea if we can move
> > e820__memblock_alloc_reserved_mpc_new() and reserve_real_mode() around
> > easily. Also, reserve_initrd()->relocate_initrd() does allocations.
>
> Even if we can move e820__memblock_alloc_reserved_mpc_new() and
> reserve_real_mode(), the allocation in reserve_initrd() has to be before
> the tables override, we would only reduce the probability of allocating an
> ACPI page.
>
> I think what we can do is to override the ACPI tables separately from their
> initial parsing. Rafael, what do you say?

Well, possibly.  With one caveat that parsing a table that's going to
be overridden subsequently may not be a good idea.

Anyway, things like that can only be done in the next cycle or later.

  reply	other threads:[~2021-04-14 10:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13 14:01 [PATCH] ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade() Rafael J. Wysocki
2021-04-13 17:43 ` David Hildenbrand
2021-04-13 17:53   ` Rafael J. Wysocki
2021-04-14  7:42     ` David Hildenbrand
2021-04-14  8:13       ` Mike Rapoport
2021-04-14 10:48         ` Rafael J. Wysocki [this message]
2021-04-13 21:28 ` George Kennedy
2021-04-26 15:51 ` George Kennedy
2021-04-26 17:15   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJZ5v0g7Lm+eA=6C04f7xCdhKrE8cQxU6rSP9zxf0POpJDuDGg@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=david@redhat.com \
    --cc=george.kennedy@oracle.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rppt@linux.ibm.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.