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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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 >
