[PATCH v2 0/2] target/arm: Implement ID_AA64PFR2_EL1

Peter Maydell posted 2 patches 4 days, 20 hours ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20250923175751.966795-1-peter.maydell@linaro.org
Maintainers: Laurent Vivier <laurent@vivier.eu>, Peter Maydell <peter.maydell@linaro.org>, Alexander Graf <agraf@csgraf.de>, Mads Ynddal <mads@ynddal.dk>, Paolo Bonzini <pbonzini@redhat.com>
linux-user/arm/target_proc.h |   2 +
target/arm/cpu-features.h    | 415 +++++++++++++++++++++++++++++++++++
target/arm/cpu.h             | 410 ----------------------------------
target/arm/cpu-sysregs.h.inc |   1 +
target/arm/helper.c          |   6 +-
target/arm/hvf/hvf.c         |   2 +
target/arm/kvm.c             |   1 +
7 files changed, 425 insertions(+), 412 deletions(-)
[PATCH v2 0/2] target/arm: Implement ID_AA64PFR2_EL1
Posted by Peter Maydell 4 days, 20 hours ago
The ID register ID_AA64PFR2_EL1 is in the space previously reserved
in the system register ID space, but recent versions of the
architecture have started to define fields in it to advertise the
presence of new architectural features. We don't implement any
of those new features yet, but will need to do so at some point.
(Notably, the GICv5 EAC spec defines a field in this register
to advertise the GICv5 CPU interface.)

This patchset gives ID_AA64PFR2_EL1 a backing field in the CPU
ID regs struct, defines the field names, and reads it from KVM if
it's present there. The only visible behaviour change is the
name we present to the user via the gdbstub.

Commit 1 is a code movement one to clear some more stuff out
of cpu.h that doesn't need to be there; it's mostly because of that
that I'm sending this patchset rather than holding on to it until
I have some GICv5 patches ready to send.

(Compare commit f7ddd7b6a1f90c from last year which added the
ID_AA64MMFR3_EL1 register.)

v2 here is just a rebase which updates the patchset to handle
the new array-based storage we're using for ID register values.

thanks
-- PMM

Peter Maydell (2):
  target/arm: Move ID register field defs to cpu-features.h
  target/arm: Implement ID_AA64PFR2_EL1

 linux-user/arm/target_proc.h |   2 +
 target/arm/cpu-features.h    | 415 +++++++++++++++++++++++++++++++++++
 target/arm/cpu.h             | 410 ----------------------------------
 target/arm/cpu-sysregs.h.inc |   1 +
 target/arm/helper.c          |   6 +-
 target/arm/hvf/hvf.c         |   2 +
 target/arm/kvm.c             |   1 +
 7 files changed, 425 insertions(+), 412 deletions(-)

-- 
2.43.0
Re: [PATCH v2 0/2] target/arm: Implement ID_AA64PFR2_EL1
Posted by Richard Henderson 4 days, 18 hours ago
On 9/23/25 10:57, Peter Maydell wrote:
> The ID register ID_AA64PFR2_EL1 is in the space previously reserved
> in the system register ID space, but recent versions of the
> architecture have started to define fields in it to advertise the
> presence of new architectural features. We don't implement any
> of those new features yet, but will need to do so at some point.
> (Notably, the GICv5 EAC spec defines a field in this register
> to advertise the GICv5 CPU interface.)
> 
> This patchset gives ID_AA64PFR2_EL1 a backing field in the CPU
> ID regs struct, defines the field names, and reads it from KVM if
> it's present there. The only visible behaviour change is the
> name we present to the user via the gdbstub.
> 
> Commit 1 is a code movement one to clear some more stuff out
> of cpu.h that doesn't need to be there; it's mostly because of that
> that I'm sending this patchset rather than holding on to it until
> I have some GICv5 patches ready to send.
> 
> (Compare commit f7ddd7b6a1f90c from last year which added the
> ID_AA64MMFR3_EL1 register.)
> 
> v2 here is just a rebase which updates the patchset to handle
> the new array-based storage we're using for ID register values.
> 
> thanks
> -- PMM
> 
> Peter Maydell (2):
>    target/arm: Move ID register field defs to cpu-features.h
>    target/arm: Implement ID_AA64PFR2_EL1
> 

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~