[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250507112254.GA27839@ranerica-svr.sc.intel.com>
Date: Wed, 7 May 2025 04:22:54 -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 Tue, May 06, 2025 at 07:26:01PM +0200, Rafael J. Wysocki wrote:
> On Tue, May 6, 2025 at 7:32 AM Ricardo Neri
> <ricardo.neri-calderon@...ux.intel.com> wrote:
> >
> > 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.
>
> Yes, it does.
>
> > > > 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.
>
> I get the general idea. :-)
>
> > Would it be preferred to have a separate implementation that is
> > functionally equivalent?
>
> Functionally equivalent on the OS side, that is.
>
> It would be better, but honestly I'm not sure if this is going to be
> sufficient to eliminate the dependency on the ACPI spec. It is just
> as you want the firmware to implement this tiny bit of the ACPI spec
> even though it is not implementing the rest of it.
Yes, that is all I need: the address of the mailbox and firmware that
implements the mailbox interface as described in the ACPI Multiprocessor
Structure.
Thanks and BR,
Ricardo
>
Powered by blists - more mailing lists