[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0gctkVZUs1SrzQtezmfMuMfbrAJ4+DTLgaQB=pMc8_hvg@mail.gmail.com>
Date: Tue, 6 May 2025 19:26:01 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, 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 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.
> [1]. https://cdrdv2-public.intel.com/733585/tdx-virtual-firmware-design-guide-rev-004-20231206.pdf
Powered by blists - more mailing lists