* [PATCH] arm64: Expose AIDR_EL1 via sysfs
@ 2025-04-03 23:16 Oliver Upton
2025-04-04 9:44 ` Anshuman Khandual
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Oliver Upton @ 2025-04-03 23:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: kvmarm, Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton
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
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
--
2.39.5
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] arm64: Expose AIDR_EL1 via sysfs
2025-04-03 23:16 [PATCH] arm64: Expose AIDR_EL1 via sysfs Oliver Upton
@ 2025-04-04 9:44 ` Anshuman Khandual
2025-04-07 12:00 ` Cornelia Huck
2025-04-29 20:27 ` Will Deacon
2 siblings, 0 replies; 4+ messages in thread
From: Anshuman Khandual @ 2025-04-04 9:44 UTC (permalink / raw)
To: Oliver Upton, linux-arm-kernel
Cc: kvmarm, Catalin Marinas, Will Deacon, Marc Zyngier
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>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] arm64: Expose AIDR_EL1 via sysfs
2025-04-03 23:16 [PATCH] arm64: Expose AIDR_EL1 via sysfs Oliver Upton
2025-04-04 9:44 ` Anshuman Khandual
@ 2025-04-07 12:00 ` Cornelia Huck
2025-04-29 20:27 ` Will Deacon
2 siblings, 0 replies; 4+ messages in thread
From: Cornelia Huck @ 2025-04-07 12:00 UTC (permalink / raw)
To: Oliver Upton, linux-arm-kernel
Cc: kvmarm, Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton
On Thu, Apr 03 2025, Oliver Upton <oliver.upton@linux.dev> 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(-)
Indeed, AIDR_EL1 should be available alongside the others.
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] arm64: Expose AIDR_EL1 via sysfs
2025-04-03 23:16 [PATCH] arm64: Expose AIDR_EL1 via sysfs Oliver Upton
2025-04-04 9:44 ` Anshuman Khandual
2025-04-07 12:00 ` Cornelia Huck
@ 2025-04-29 20:27 ` Will Deacon
2 siblings, 0 replies; 4+ messages in thread
From: Will Deacon @ 2025-04-29 20:27 UTC (permalink / raw)
To: linux-arm-kernel, Oliver Upton
Cc: catalin.marinas, kernel-team, Will Deacon, kvmarm, Marc Zyngier
On Thu, 03 Apr 2025 16:16:26 -0700, 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.
>
> [...]
Applied to arm64 (for-next/cpufeature), thanks!
[1/1] arm64: Expose AIDR_EL1 via sysfs
https://git.kernel.org/arm64/c/17efc1acee62
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-04-29 20:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-03 23:16 [PATCH] arm64: Expose AIDR_EL1 via sysfs Oliver Upton
2025-04-04 9:44 ` Anshuman Khandual
2025-04-07 12:00 ` Cornelia Huck
2025-04-29 20:27 ` Will Deacon
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).