devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Yunhong Jiang <yunhong.jiang@linux.intel.com>,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
	decui@microsoft.com, rafael@kernel.org, lenb@kernel.org,
	kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, linux-hyperv@vger.kernel.org,
	linux-acpi@vger.kernel.org, ricardo.neri@intel.com,
	ravi.v.shankar@intel.com
Subject: Re: [PATCH v2 2/9] dt-bindings: x86: Add a binding for x86 wakeup mailbox
Date: Tue, 11 Mar 2025 11:01:28 +0100	[thread overview]
Message-ID: <acb5fa11-9dce-44d0-85e3-e67a6a10c48f@kernel.org> (raw)
In-Reply-To: <20250303222102.GA16733@ranerica-svr.sc.intel.com>

On 03/03/2025 23:21, Ricardo Neri wrote:
> On Fri, Sep 20, 2024 at 01:15:41PM +0200, Krzysztof Kozlowski wrote:
> 
> [...]
>  
>> enable-method is part of CPUs, so you probably should match the CPUs...
>> I am not sure, I don't have the big picture here.
>>
>> Maybe if companies want to push more of bindings for purely virtual
>> systems, then they should first get involved more, instead of relying on
>> us. Provide reviews for your virtual stuff, provide guidance. There is
>> resistance in accepting bindings for such cases for a reason - I don't
>> even know what exactly is this and judging/reviewing based on my
>> practices will no be accurate.
> 
> Hi Krzysztof,
> 
> I am taking over this work from Yunhong.
> 
> First of all, I apologize for the late reply. I will make sure
> communications are timely in the future.
> 
> Our goal is to describe in the device tree a mechanism or artifact to boot
> secondary CPUs.
> 
> In our setup, the firmware puts secondary CPUs to monitor a memory location
> (i.e., the wakeup mailbox) while spinning. From the boot CPU, the OS writes
> in the mailbox the wakeup vector and the ID of the secondary CPU it wants
> to boot. When a secondary CPU sees its own ID it will jump to the wakeup
> vector.
> 
> This is similar to the spin-table described in the Device Tree
> specification. The key difference is that with the spin-table CPUs spin
> until a non-zero value is written in `cpu-release-addr`. The wakeup mailbox
> uses CPU IDs.
> 
> You raised the issue of the lack of a `compatible` property, and the fact
> that we are not describing an actual device.
> 
> I took your suggestion of matching by node and I came up with the binding
> below. I see these advantages in this approach:
> 
>   * I define a new node with a `compatible` property.
>   * There is precedent: the psci node. In the `cpus` node, each cpu@n has

psci is a standard. If you are documenting here a standard, clearly
express it and provide reference to the specification.


>     an `enable-method` property that specify `psci`.
>   * The mailbox is a device as it is located in a reserved memory region.
>     This true regardless of the device tree describing bare-metal or
>     virtualized machines.
> 
> Thanks in advance for your feedback!
> 
> Best,
> Ricardo
> 
> (only the relevant sections of the binding are shown for brevity)
> 
> properties:
>   $nodename:
>     const: wakeup-mailbox
> 
>   compatible:
>     const: x86,wakeup-mailbox

You need vendor prefix for this particular device. If I pointed out lack
of device and specific compatible, then adding random compatible does
not solve it. I understand it solves for you, but not from the bindings
point of view.

> 
>   mailbox-addr:
>     $ref: /schemas/types.yaml#/definitions/uint64

So is this some sort of reserved memory? Mailbox needs mbox-cells, so
maybe that's not mailbox.



Best regards,
Krzysztof

  reply	other threads:[~2025-03-11 10:01 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-23 23:23 [PATCH v2 0/9] x86/hyperv: Support wakeup mailbox for VTL2 TDX guest Yunhong Jiang
2024-08-23 23:23 ` [PATCH v2 1/9] x86/acpi: Move ACPI MADT wakeup to generic code Yunhong Jiang
2024-08-23 23:23 ` [PATCH v2 2/9] dt-bindings: x86: Add a binding for x86 wakeup mailbox Yunhong Jiang
2024-08-25  7:10   ` Krzysztof Kozlowski
2024-08-27 20:45     ` Yunhong Jiang
2024-09-10  6:13       ` Yunhong Jiang
2024-09-16  8:56         ` Krzysztof Kozlowski
2024-09-19 19:19           ` Yunhong Jiang
2024-09-19 22:15             ` Yunhong Jiang
2024-09-20 11:19               ` Krzysztof Kozlowski
2024-09-20 11:15             ` Krzysztof Kozlowski
2025-03-03 22:21               ` Ricardo Neri
2025-03-11 10:01                 ` Krzysztof Kozlowski [this message]
2025-03-12  5:51                   ` Ricardo Neri
2025-03-19  7:52                     ` Krzysztof Kozlowski
2025-03-20 20:34                       ` Ricardo Neri
2024-08-23 23:23 ` [PATCH v2 3/9] x86/dt: Support the ACPI multiprocessor wakeup for device tree Yunhong Jiang
2024-09-02  3:35   ` Michael Kelley
2024-09-03 18:35     ` Yunhong Jiang
2024-08-23 23:23 ` [PATCH v2 4/9] x86/hyperv: Parse the ACPI wakeup mailbox Yunhong Jiang
2024-09-02  3:35   ` Michael Kelley
2024-09-03 20:19     ` Yunhong Jiang
2024-09-04 14:56       ` Michael Kelley
2024-09-04 17:31         ` Yunhong Jiang
2024-08-23 23:23 ` [PATCH v2 5/9] x86/hyperv: Mark ACPI wakeup mailbox page as private Yunhong Jiang
2024-09-02  3:35   ` Michael Kelley
2024-09-02 18:38     ` Saurabh Singh Sengar
2024-09-02 20:24       ` Michael Kelley
2024-08-23 23:23 ` [PATCH v2 6/9] x86/realmode: Add memory range support to reserve_real_mode Yunhong Jiang
2024-08-23 23:23 ` [PATCH v2 7/9] x86/hyperv: Move setting the real_mode_header to hv_vtl_init_platform Yunhong Jiang
2024-08-23 23:23 ` [PATCH v2 8/9] x86/hyperv: Set realmode_limit to 4G for VTL2 TDX guest Yunhong Jiang
2024-09-02  3:35   ` Michael Kelley
2024-08-23 23:23 ` [PATCH v2 9/9] x86/hyperv: Use wakeup mailbox for VTL2 guests if available Yunhong Jiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acb5fa11-9dce-44d0-85e3-e67a6a10c48f@kernel.org \
    --to=krzk@kernel.org \
    --cc=bp@alien8.de \
    --cc=conor+dt@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=decui@microsoft.com \
    --cc=devicetree@vger.kernel.org \
    --cc=haiyangz@microsoft.com \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=krzk+dt@kernel.org \
    --cc=kys@microsoft.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rafael@kernel.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=ricardo.neri-calderon@linux.intel.com \
    --cc=ricardo.neri@intel.com \
    --cc=robh@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wei.liu@kernel.org \
    --cc=x86@kernel.org \
    --cc=yunhong.jiang@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).