[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2lqydi2yuc5qlyasr6q7wrqq7b5jn6juc4bp7nehshcpxqmnzz@rcld4x7sc3bs>
Date: Fri, 28 Jun 2024 13:07:41 +0300
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Zhiquan Li <zhiquan1.li@...el.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, rafael@...nel.org, hpa@...or.com,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] x86/acpi: fix panic while AP online later with kernel
parameter maxcpus=1
On Fri, Jun 28, 2024 at 04:21:19PM +0800, Zhiquan Li wrote:
> The issue was found on the platform that using "Multiprocessor Wakeup
> Structure"[1] to startup secondary CPU, which is usually used by
> encrypted guest. When restrict boot time CPU to 1 with the kernel
> parameter "maxcpus=1" and bring other CPUs online later, there will be
> a kernel panic.
>
> The variable acpi_mp_wake_mailbox, which holds the virtual address of
> the MP Wakeup Structure mailbox, will be set as read-only after init.
> If the first AP gets online later, after init, the attempt to update
> the variable results in panic.
>
> But it is worth noting that the memremap() function that initializes the
> variable cannot be moved into acpi_parse_mp_wake() because memremap() is
> not yet functional at this point in the boot process.
The memremap() call that initializes the variable cannot be moved into
acpi_parse_mp_wake() because memremap() is not functional at that point
in the boot process.
>
> [1] Details about the MP Wakeup structure can be found in ACPI v6.4, in
> the "Multiprocessor Wakeup Structure" section.
>
> Signed-off-by: Zhiquan Li <zhiquan1.li@...el.com>
>
Otherwise looks good to me.
Reviewed-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists