From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Oliver Upton <oliver.upton@linux.dev>,
linux-arm-kernel@lists.infradead.org
Cc: kvmarm@lists.linux.dev, Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH] arm64: Expose AIDR_EL1 via sysfs
Date: Fri, 4 Apr 2025 15:14:21 +0530 [thread overview]
Message-ID: <f0e1ce67-8341-4c44-993c-dac31db00c59@arm.com> (raw)
In-Reply-To: <20250403231626.3181116-1-oliver.upton@linux.dev>
On 4/4/25 04:46, Oliver Upton wrote:
> The KVM PV ABI recently added a feature that allows the VM to discover
> the set of physical CPU implementations, identified by a tuple of
> {MIDR_EL1, REVIDR_EL1, AIDR_EL1}. Unlike other KVM PV features, the
> expectation is that the VMM implements the hypercall instead of KVM as
> it has the authoritative view of where the VM gets scheduled.
>
> To do this the VMM needs to know the values of these registers on any
> CPU in the system. While MIDR_EL1 and REVIDR_EL1 are already exposed,
> AIDR_EL1 is not. Provide it in sysfs along with the other identification
> registers.
>
> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> ---
> Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
> Documentation/arch/arm64/cpu-feature-registers.rst | 13 +++++++------
> arch/arm64/include/asm/cpu.h | 1 +
> arch/arm64/kernel/cpuinfo.c | 3 +++
> 4 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
> index 206079d3bd5b..9bbf4c27c237 100644
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -485,6 +485,7 @@ What: /sys/devices/system/cpu/cpuX/regs/
> /sys/devices/system/cpu/cpuX/regs/identification/
> /sys/devices/system/cpu/cpuX/regs/identification/midr_el1
> /sys/devices/system/cpu/cpuX/regs/identification/revidr_el1
> + /sys/devices/system/cpu/cpuX/regs/identification/aidr_el1
> /sys/devices/system/cpu/cpuX/regs/identification/smidr_el1
> Date: June 2016
> Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org>
> diff --git a/Documentation/arch/arm64/cpu-feature-registers.rst b/Documentation/arch/arm64/cpu-feature-registers.rst
> index 253e9743de2f..add66afc7b03 100644
> --- a/Documentation/arch/arm64/cpu-feature-registers.rst
> +++ b/Documentation/arch/arm64/cpu-feature-registers.rst
> @@ -72,14 +72,15 @@ there are some issues with their usage.
> process could be migrated to another CPU by the time it uses the
> register value, unless the CPU affinity is set. Hence, there is no
> guarantee that the value reflects the processor that it is
> - currently executing on. The REVIDR is not exposed due to this
> - constraint, as REVIDR makes sense only in conjunction with the
> - MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
> - at::
> + currently executing on. REVIDR and AIDR are not exposed due to this
> + constraint, as these registers only make sense in conjunction with
> + the MIDR. Alternately, MIDR_EL1, REVIDR_EL1, and AIDR_EL1 are exposed
> + via sysfs at::
>
> /sys/devices/system/cpu/cpu$ID/regs/identification/
> - \- midr
> - \- revidr
> + \- midr_el1
> + \- revidr_el1
> + \- aidr_el1
Right, the existing ones are also marked with _el1 suffix as well.
>
> 3. Implementation
> --------------------
> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
> index 81e4157f92b7..71493b760b83 100644
> --- a/arch/arm64/include/asm/cpu.h
> +++ b/arch/arm64/include/asm/cpu.h
> @@ -44,6 +44,7 @@ struct cpuinfo_arm64 {
> u64 reg_dczid;
> u64 reg_midr;
> u64 reg_revidr;
> + u64 reg_aidr;
> u64 reg_gmid;
> u64 reg_smidr;
> u64 reg_mpamidr;
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 285d7d538342..621218d2a991 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -328,11 +328,13 @@ static const struct kobj_type cpuregs_kobj_type = {
>
> CPUREGS_ATTR_RO(midr_el1, midr);
> CPUREGS_ATTR_RO(revidr_el1, revidr);
> +CPUREGS_ATTR_RO(aidr_el1, aidr);
> CPUREGS_ATTR_RO(smidr_el1, smidr);
>
> static struct attribute *cpuregs_id_attrs[] = {
> &cpuregs_attr_midr_el1.attr,
> &cpuregs_attr_revidr_el1.attr,
> + &cpuregs_attr_aidr_el1.attr,
> NULL
> };
>
> @@ -469,6 +471,7 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
> info->reg_dczid = read_cpuid(DCZID_EL0);
> info->reg_midr = read_cpuid_id();
> info->reg_revidr = read_cpuid(REVIDR_EL1);
> + info->reg_aidr = read_cpuid(AIDR_EL1);
>
> info->reg_id_aa64dfr0 = read_cpuid(ID_AA64DFR0_EL1);
> info->reg_id_aa64dfr1 = read_cpuid(ID_AA64DFR1_EL1);
>
> base-commit: e8b471285262d1561feb2eb266aab6ebe7094124
LGTM
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
next prev parent reply other threads:[~2025-04-04 9:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-03 23:16 [PATCH] arm64: Expose AIDR_EL1 via sysfs Oliver Upton
2025-04-04 9:44 ` Anshuman Khandual [this message]
2025-04-07 12:00 ` Cornelia Huck
2025-04-29 20:27 ` Will Deacon
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=f0e1ce67-8341-4c44-993c-dac31db00c59@arm.com \
--to=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=will@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