mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "M K, Muralidhara" <muralimk@amd.com>
To: Mario Limonciello <mario.limonciello@amd.com>,
	Muralidhara M K <muralidhara.mk@amd.com>,
	ilpo.jarvinen@linux.intel.com
Cc: platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org, muthusamy.ramalingam@amd.com
Subject: Re: [PATCH 7/7] Documentation/arch/x86/amd_hsmp: Document the SMN and MSR IOCTLs
Date: Thu, 30 Jul 2026 15:35:08 +0530	[thread overview]
Message-ID: <ffdf1489-6133-405a-a531-e8e7a6cc99ad@amd.com> (raw)
In-Reply-To: <5c7fffb6-72e1-4ead-ab02-7544593a96b3@amd.com>



On 7/30/2026 3:11 AM, Mario Limonciello wrote:
> 
> 
> On 7/29/26 11:40, Muralidhara M K wrote:
>> Describe HSMP_IOCTL_SMN_CMD and HSMP_IOCTL_MSR_CMD: the payload structs,
>> the CAP_SYS_RAWIO and open-mode requirements, and the rule that both are
>> read-only, so a request with @write set is refused with -EPERM even for a
>> fully privileged caller on an O_RDWR handle.
>>
>> Also note that reading the protocol_version attribute can fail on the
>> Fam1Ah client platforms, because some client SMU builds reject the
>> interface-version query, which is why the telemetry ioctl rather than
>> that attribute is the way to reach the client telemetry layout.
> 
> I'm happy that these are (at least) defaulting to read-only, but I don't 
> understand their purpose.
> 
> We already have /dev/cpu/CPUNUM/msr, and we also have amd-node which 
> provides access to SMN via /sys/kernel/debug/x86/.
> 
> Can you better describe the needs of why these new messages must exist 
> and we can't have structured data for them?
> 
Thanks for the input. Yes, I will describe more on why we need them.

> Even if amd_hsmp needs to use SMN or MSR to fetch specific data data, 
> this feels a lot safer to have a structured specific fetch method than 
> such a wide (albeit permissioned) pipe.
> 
>>
>> Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
>> ---
>>   Documentation/arch/x86/amd_hsmp.rst | 44 +++++++++++++++++++++++++++++
>>   1 file changed, 44 insertions(+)
>>
>> diff --git a/Documentation/arch/x86/amd_hsmp.rst b/Documentation/arch/ 
>> x86/amd_hsmp.rst
>> index 8a9d6fe7d4cf..0f03201a9f68 100644
>> --- a/Documentation/arch/x86/amd_hsmp.rst
>> +++ b/Documentation/arch/x86/amd_hsmp.rst
>> @@ -229,6 +229,50 @@ The following IOCTLs are defined:
>>     ``sizeof(struct hsmp_metric_table)``.  Later version metrics table
>>     layout is documented in the Public PPR.
>> +  On the Fam1Ah client platforms reading ``protocol_version`` can fail,
>> +  because some client SMU builds reject the interface-version query.
>> +  Those parts have their own telemetry layout and this ioctl is the way
>> +  to read it.
> 
> It seems to me you don't actually describe the telemetry layout or what 
> should be done with SMN.
> 
>> +
>> +``ioctl(file, HSMP_IOCTL_SMN_CMD, struct hsmp_smn_message *smn)``
>> +  Read a 32-bit SMN register on the socket given by ``sock_ind``.  This
>> +  reaches registers outside the HSMP message ABI, so it requires
>> +  ``CAP_SYS_RAWIO`` as well as a handle opened for reading, the latter
>> +  because the value read is written back into the request struct.
>> +
>> +  The ioctl is read-only.  ``write`` must be zero, and a request that
>> +  sets it is rejected with ``-EPERM`` even with ``CAP_SYS_RAWIO`` and an
>> +  ``O_RDWR`` handle; the field exists only so that write support 
>> could be
>> +  added later without changing the layout.  ``reserved`` must be zero.
>> +  Argument::
>> +
>> +    struct hsmp_smn_message {
>> +        __u32 smn_address; /* SMN address to read */
>> +        __u32 value;       /* Value read, filled in by the kernel */
>> +        __u16 sock_ind;    /* Socket index */
>> +        __u8  write;       /* Must be zero */
>> +        __u8  reserved;    /* Reserved, must be zero */
>> +    };
>> +
>> +``ioctl(file, HSMP_IOCTL_MSR_CMD, struct hsmp_msr_message *msr)``
>> +  Read a 64-bit MSR on the logical CPU given by ``core_id``, or on
>> +  whichever CPU the ioctl runs on when ``core_id`` is
>> +  ``HSMP_MSR_ANY_CPU`` (``(__u32)-1``).  Any other ``core_id`` must 
>> refer
>> +  to an online CPU, otherwise the call fails with ``-EINVAL``.  Requires
>> +  ``CAP_SYS_RAWIO`` and a handle opened for reading.
>> +
>> +  Read-only on the same terms as ``HSMP_IOCTL_SMN_CMD``: a non-zero
>> +  ``write`` is rejected with ``-EPERM``, and every byte of ``reserved``
>> +  must be zero.  Argument::
>> +
>> +    struct hsmp_msr_message {
>> +        __u32 msr_address; /* MSR index to read */
>> +        __u32 core_id;     /* Logical CPU, or HSMP_MSR_ANY_CPU */
>> +        __u64 value;       /* Value read, filled in by the kernel */
>> +        __u8  write;       /* Must be zero */
>> +        __u8  reserved[3]; /* Reserved, must be zero */
>> +    };
>> +
>>   The ioctl would return a non-zero on failure; you can read errno to see
>>   what happened. The transaction returns 0 on success.
> 


      reply	other threads:[~2026-07-30 10:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 16:40 [PATCH 0/7] platform/x86/amd/hsmp: Family 1Ah client support Muralidhara M K
2026-07-29 16:40 ` [PATCH 1/7] platform/x86/amd/hsmp: Add HSMP client support for Family 1Ah Muralidhara M K
2026-07-29 21:27   ` Mario Limonciello
2026-07-30  9:37     ` M K, Muralidhara
2026-07-30 16:43   ` Armin Wolf
2026-07-31  4:27     ` M K, Muralidhara
2026-07-31  7:00     ` Shyam Sundar S K
2026-07-31 10:29       ` Armin Wolf
2026-07-29 16:40 ` [PATCH 2/7] platform/x86/amd/hsmp: Route metric table through the client messages Muralidhara M K
2026-07-29 21:29   ` Mario Limonciello
2026-07-30  9:42     ` M K, Muralidhara
2026-07-29 16:40 ` [PATCH 3/7] platform/x86/amd/hsmp: Add ACPI client support via the SMNR method Muralidhara M K
2026-07-29 21:30   ` Mario Limonciello
2026-07-30  9:44     ` M K, Muralidhara
2026-07-29 16:40 ` [PATCH 4/7] platform/x86/amd/hsmp: Leave the hwmon power sensors off on client platforms Muralidhara M K
2026-07-29 21:35   ` Mario Limonciello
2026-07-30 10:01     ` M K, Muralidhara
2026-07-29 16:40 ` [PATCH 5/7] platform/x86/amd/hsmp: Add SMN read IOCTL support Muralidhara M K
2026-07-29 16:40 ` [PATCH 6/7] platform/x86/amd/hsmp: Add MSR " Muralidhara M K
2026-07-29 16:40 ` [PATCH 7/7] Documentation/arch/x86/amd_hsmp: Document the SMN and MSR IOCTLs Muralidhara M K
2026-07-29 21:41   ` Mario Limonciello
2026-07-30 10:05     ` M K, Muralidhara [this message]

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=ffdf1489-6133-405a-a531-e8e7a6cc99ad@amd.com \
    --to=muralimk@amd.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=muralidhara.mk@amd.com \
    --cc=muthusamy.ramalingam@amd.com \
    --cc=platform-driver-x86@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®