linux-kernel - Re: [PATCH v3 03/13] x86/acpi: Move acpi_wakeup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250506053726.GF25533@ranerica-svr.sc.intel.com>
Date: Mon, 5 May 2025 22:37:26 -0700
From: Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: x86@...nel.org, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Rob Herring <robh@...nel.org>,
	"K. Y. Srinivasan" <kys@...rosoft.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
	Michael Kelley <mhklinux@...look.com>, devicetree@...r.kernel.org,
	Saurabh Sengar <ssengar@...ux.microsoft.com>,
	Chris Oo <cho@...rosoft.com>, linux-hyperv@...r.kernel.org,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
	Ricardo Neri <ricardo.neri@...el.com>
Subject: Re: [PATCH v3 03/13] x86/acpi: Move acpi_wakeup_cpu() and helpers to
 smpboot.c

On Mon, May 05, 2025 at 12:03:13PM +0200, Rafael J. Wysocki wrote:
> On Sat, May 3, 2025 at 9:10 PM Ricardo Neri
> <ricardo.neri-calderon@...ux.intel.com> wrote:
> >
> > The bootstrap processor uses acpi_wakeup_cpu() to indicate to firmware that
> > it wants to boot a secondary CPU using a mailbox as described in the
> > Multiprocessor Wakeup Structure of the ACPI specification.
> >
> > The wakeup mailbox does not strictly require support from ACPI.
> 
> Well, except that it is defined by the ACPI specification.

That is true.

> 
> > The platform firmware can implement a mailbox compatible in structure and
> > operation and enumerate it using other mechanisms such a DeviceTree graph.
> 
> So is there a specification defining this mechanism?
> 
> It is generally not sufficient to put the code and DT bindings
> unilaterally into the OS and expect the firmware to follow suit.
> 

This mechanism is described in the section 4.3.5 of the Intel TDX
Virtual Firmware Design Guide [1], but it refeers to the ACPI
specification for the interface.

> > Move the code used to setup and use the mailbox out of the ACPI
> > directory to use it when support for ACPI is not available or needed.
> 
> I think that the code implementing interfaces defined by the ACPI
> specification is not generic and so it should not be built when the
> kernel is configured without ACPI support.

Support for ACPI would not be used on systems describing hardware using
a DeviceTree graph. My goal is to have a common interface that both
DT and ACPI can use. I think what is missing is that common interface.

Would it be preferred to have a separate implementation that is
functionally equivalent?

Thanks and BR,
Ricardo


[1]. https://cdrdv2-public.intel.com/733585/tdx-virtual-firmware-design-guide-rev-004-20231206.pdf