Re: [PATCH v3 03/13] x86/acpi: Move acpi_wakeup_cpu() and helpers to smpboot.c

Ricardo Neri
2025-05-07T11:17:50Z

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@linux.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@linux.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
>