KVM: arm64: Override Microsoft Azure Cobalt 100 MIDR value with ARM Neoverse N2
RFC PATCH 1/1 KVM: arm64: Override Microsoft Azure Cobalt 100 MIDR value with ARM Neoverse N2
Several workload optimizations and errata depend on validating that the optimization or errata are applicable to the particular CPU by checking the MIDR_EL1 system register value. With the Microsoft implementer ID for Azure Cobalt 100, the value doesn't match and ~20-25% performance regression is seen in these workloads. Override the Azure Cobalt 100 value and replace it with the default ARM Neoverse N2 value that Azure Cobalt 100 is based on.
--- arch/arm64/include/asm/cputype.h | 3 ++- arch/arm64/include/asm/el2_setup.h | 5 +++++ arch/arm64/kvm/sys_regs.c | 9 ++++++++- 3 files changed, 15 insertions(+), 2 deletions(-)
arch/arm64/include/asm/cputype.h +2 -1
@@ -262,7 +262,8 @@ is_midr_in_range_list(u32 midr, struct midr_range const *ranges)*/ static inline u32 __attribute_const__ read_cpuid_id(void) { -return read_cpuid (MIDR_EL1 ); +return (read_cpuid (MIDR_EL1 ) ==0x6D0FD490 ?0x410FD490 : +read_cpuid (MIDR_EL1 )); } static inline u64 __attribute_const__ read_cpuid_mpidr(void)
arch/arm64/include/asm/el2_setup.h +5 -0
@@ -138,6 +138,11 @@ .macro __init_el2_nvhe_idregsmrs x0, midr_el1 mrs x1, mpidr_el1 + ldr x2, =0x6D0FD490 + cmp x0, x2 + bne .Loverride_cobalt100_\@ + ldr x0, =0x410FD490 +.Loverride_cobalt100_\@: msr vpidr_el2, x0 msr vmpidr_el2, x1 .endm
arch/arm64/kvm/sys_regs.c +8 -1
@@ -3574,7 +3574,14 @@ id_to_sys_reg_desc(struct kvm_vcpu *vcpu, u64 id,return ((struct sys_reg_desc *)r)->val; \ } -FUNCTION_INVARIANT(midr_el1) +static u64 get_midr_el1 (struct kvm_vcpu *v,const struct sys_reg_desc *r) +{ + ((struct sys_reg_desc *)r)->val =read_sysreg (midr_el1); +if (((struct sys_reg_desc *)r)->val ==0x6D0FD490 ) + ((struct sys_reg_desc *)r)->val ==0x410FD490 ; +return ((struct sys_reg_desc *)r)->val; +} +FUNCTION_INVARIANT (revidr_el1)FUNCTION_INVARIANT (aidr_el1)
Signature · 1 line
2.34.1
Quoted 3 lines · Easwar Hariharan
Several workload optimizations and errata depend on validating that the optimization or errata are applicable to the particular CPU by checking the
MIDR_EL1system register value. With the Microsoft implementer ID
Which is how it should be done.
Quoted 4 lines
for Azure Cobalt 100, the value doesn't match and ~20-25% performance regression is seen in these workloads. Override the Azure Cobalt 100 value and replace it with the default ARM Neoverse N2 value that Azure Cobalt 100 is based on.
Why cannot these MIDR values be classified as required and subscribed to the existing erratas that is affecting such implementations. Hence these work arounds will be triggered as and when applicable. Why then override MIDR value instead ?
Quoted 58 lines
Signed-off-by Easwar Hariharan <[email protected]>--- arch/arm64/include/asm/cputype.h | 3 ++- arch/arm64/include/asm/el2_setup.h | 5 +++++ arch/arm64/kvm/sys_regs.c | 9 ++++++++- 3 files changed, 15 insertions(+), 2 deletions(-)arch/arm64/include/asm/cputype.h +2
-1@@ -262,7 +262,8 @@ is_midr_in_range_list(u32 midr, struct midr_range const *ranges)*/ static inline u32 __attribute_const__ read_cpuid_id(void) { -return read_cpuid (MIDR_EL1 ); +return (read_cpuid (MIDR_EL1 ) ==0x6D0FD490 ?0x410FD490 : +read_cpuid (MIDR_EL1 )); } static inline u64 __attribute_const__ read_cpuid_mpidr(void)arch/arm64/include/asm/el2_setup.h +5
-0@@ -138,6 +138,11 @@ .macro __init_el2_nvhe_idregsmrs x0, midr_el1 mrs x1, mpidr_el1 + ldr x2, =0x6D0FD490 + cmp x0, x2 + bne .Loverride_cobalt100_\@ + ldr x0, =0x410FD490 +.Loverride_cobalt100_\@: msr vpidr_el2, x0 msr vmpidr_el2, x1 .endmarch/arm64/kvm/sys_regs.c +8
-1@@ -3574,7 +3574,14 @@ id_to_sys_reg_desc(struct kvm_vcpu *vcpu, u64 id,return ((struct sys_reg_desc *)r)->val; \ } -FUNCTION_INVARIANT(midr_el1) +static u64 get_midr_el1 (struct kvm_vcpu *v,const struct sys_reg_desc *r) +{ + ((struct sys_reg_desc *)r)->val =read_sysreg (midr_el1); +if (((struct sys_reg_desc *)r)->val ==0x6D0FD490 ) + ((struct sys_reg_desc *)r)->val ==0x410FD490 ; +return ((struct sys_reg_desc *)r)->val; +} +FUNCTION_INVARIANT (revidr_el1)FUNCTION_INVARIANT (aidr_el1)
Quoted 13 lines · Anshuman Khandual
Quoted 3 lines · Easwar Hariharan
Several workload optimizations and errata depend on validating that the optimization or errata are applicable to the particular CPU by checking the
MIDR_EL1system register value. With the Microsoft implementer IDWhich is how it should be done.
Quoted 4 lines
for Azure Cobalt 100, the value doesn't match and ~20-25% performance regression is seen in these workloads. Override the Azure Cobalt 100 value and replace it with the default ARM Neoverse N2 value that Azure Cobalt 100 is based on.
Quoted 5 lines
Why cannot these MIDR values be classified as required and subscribed to the existing erratas that is affecting such implementations. Hence these work arounds will be triggered as and when applicable. Why then override MIDR value instead ?
Thanks for the feedback, I will go ahead and add the Azure Cobalt 100 MIDR value to the range of MIDRs affected by the Neoverse N2 errata. This patch was a proof of concept to have userspace apply the Neoverse N2 optimizations to Azure Cobalt 100 as well. As Mark mentioned in a sibling response, this is not an acceptable way to accomplish this.
Quoted 58 lines
Quoted 58 lines
Signed-off-by Easwar Hariharan <[email protected]>--- arch/arm64/include/asm/cputype.h | 3 ++- arch/arm64/include/asm/el2_setup.h | 5 +++++ arch/arm64/kvm/sys_regs.c | 9 ++++++++- 3 files changed, 15 insertions(+), 2 deletions(-)arch/arm64/include/asm/cputype.h +2
-1@@ -262,7 +262,8 @@ is_midr_in_range_list(u32 midr, struct midr_range const *ranges)*/ static inline u32 __attribute_const__ read_cpuid_id(void) { -return read_cpuid (MIDR_EL1 ); +return (read_cpuid (MIDR_EL1 ) ==0x6D0FD490 ?0x410FD490 : +read_cpuid (MIDR_EL1 )); } static inline u64 __attribute_const__ read_cpuid_mpidr(void)arch/arm64/include/asm/el2_setup.h +5
-0@@ -138,6 +138,11 @@ .macro __init_el2_nvhe_idregsmrs x0, midr_el1 mrs x1, mpidr_el1 + ldr x2, =0x6D0FD490 + cmp x0, x2 + bne .Loverride_cobalt100_\@ + ldr x0, =0x410FD490 +.Loverride_cobalt100_\@: msr vpidr_el2, x0 msr vmpidr_el2, x1 .endmarch/arm64/kvm/sys_regs.c +8
-1@@ -3574,7 +3574,14 @@ id_to_sys_reg_desc(struct kvm_vcpu *vcpu, u64 id,return ((struct sys_reg_desc *)r)->val; \ } -FUNCTION_INVARIANT(midr_el1) +static u64 get_midr_el1 (struct kvm_vcpu *v,const struct sys_reg_desc *r) +{ + ((struct sys_reg_desc *)r)->val =read_sysreg (midr_el1); +if (((struct sys_reg_desc *)r)->val ==0x6D0FD490 ) + ((struct sys_reg_desc *)r)->val ==0x410FD490 ; +return ((struct sys_reg_desc *)r)->val; +} +FUNCTION_INVARIANT (revidr_el1)FUNCTION_INVARIANT (aidr_el1)
Mark Rutland
reviewerQuoted 7 lines · Easwar Hariharan
Several workload optimizations and errata depend on validating that the optimization or errata are applicable to the particular CPU by checking the
MIDR_EL1system register value. With the Microsoft implementer ID for Azure Cobalt 100, the value doesn't match and ~20-25% performance regression is seen in these workloads. Override the Azure Cobalt 100 value and replace it with the default ARM Neoverse N2 value that Azure Cobalt 100 is based on.
NAK to rewriting the MIDR in the kernel; we do not lie to userspace about the MIDR, and this is not a can of worms we're going to open.
If you desire some microarchitectural performance optimizations in particular projects, please submit patches to those projects to understand your MIDR value.
Further, if Azure Cobalt 100 is based on ARM Neoverse N2, you presumably suffer from the same errata; can you comment on that at all? e.g. are there any changes in this part that *might* lead to differences in errata and/or workarounds? How do the MIDR_EL1.{Variant,Revision} values compare to that of Neoverse N2?
Mark.
Quoted 61 lines
Signed-off-by Easwar Hariharan <[email protected]>--- arch/arm64/include/asm/cputype.h | 3 ++- arch/arm64/include/asm/el2_setup.h | 5 +++++ arch/arm64/kvm/sys_regs.c | 9 ++++++++- 3 files changed, 15 insertions(+), 2 deletions(-)arch/arm64/include/asm/cputype.h +2
-1@@ -262,7 +262,8 @@ is_midr_in_range_list(u32 midr, struct midr_range const *ranges)*/ static inline u32 __attribute_const__ read_cpuid_id(void) { -return read_cpuid (MIDR_EL1 ); +return (read_cpuid (MIDR_EL1 ) ==0x6D0FD490 ?0x410FD490 : +read_cpuid (MIDR_EL1 )); } static inline u64 __attribute_const__ read_cpuid_mpidr(void)arch/arm64/include/asm/el2_setup.h +5
-0@@ -138,6 +138,11 @@ .macro __init_el2_nvhe_idregsmrs x0, midr_el1 mrs x1, mpidr_el1 + ldr x2, =0x6D0FD490 + cmp x0, x2 + bne .Loverride_cobalt100_\@ + ldr x0, =0x410FD490 +.Loverride_cobalt100_\@: msr vpidr_el2, x0 msr vmpidr_el2, x1 .endmarch/arm64/kvm/sys_regs.c +8
-1@@ -3574,7 +3574,14 @@ id_to_sys_reg_desc(struct kvm_vcpu *vcpu, u64 id,return ((struct sys_reg_desc *)r)->val; \ } -FUNCTION_INVARIANT(midr_el1) +static u64 get_midr_el1 (struct kvm_vcpu *v,const struct sys_reg_desc *r) +{ + ((struct sys_reg_desc *)r)->val =read_sysreg (midr_el1); +if (((struct sys_reg_desc *)r)->val ==0x6D0FD490 ) + ((struct sys_reg_desc *)r)->val ==0x410FD490 ; +return ((struct sys_reg_desc *)r)->val; +} +FUNCTION_INVARIANT (revidr_el1)FUNCTION_INVARIANT (aidr_el1)Signature · 1 line
2.34.1
Quoted 9 lines · Mark Rutland
Quoted 7 lines · Easwar Hariharan
Several workload optimizations and errata depend on validating that the optimization or errata are applicable to the particular CPU by checking the
MIDR_EL1system register value. With the Microsoft implementer ID for Azure Cobalt 100, the value doesn't match and ~20-25% performance regression is seen in these workloads. Override the Azure Cobalt 100 value and replace it with the default ARM Neoverse N2 value that Azure Cobalt 100 is based on.
Quoted 6 lines
NAK to rewriting the MIDR in the kernel; we do not lie to userspace about the MIDR, and this is not a can of worms we're going to open.
If you desire some microarchitectural performance optimizations in particular projects, please submit patches to those projects to understand your MIDR value.
Understood.
Quoted 7 lines
Further, if Azure Cobalt 100 is based on ARM Neoverse N2, you presumably suffer from the same errata; can you comment on that at all? e.g. are there any changes in this part that *might* lead to differences in errata and/or workarounds? How do the MIDR_EL1.{Variant,Revision} values compare to that of Neoverse N2?
Yes, Azure Cobalt 100 suffers from the same errata as Neoverse N2. We had changes in the implementation, but according to our hardware folks, the Neoverse N2 errata we are affected by so far aren't affected by the changes made for Azure Cobalt 100.
Quoted 63 lines
Mark.
Quoted 61 lines
Signed-off-by Easwar Hariharan <[email protected]>--- arch/arm64/include/asm/cputype.h | 3 ++- arch/arm64/include/asm/el2_setup.h | 5 +++++ arch/arm64/kvm/sys_regs.c | 9 ++++++++- 3 files changed, 15 insertions(+), 2 deletions(-)arch/arm64/include/asm/cputype.h +2
-1@@ -262,7 +262,8 @@ is_midr_in_range_list(u32 midr, struct midr_range const *ranges)*/ static inline u32 __attribute_const__ read_cpuid_id(void) { -return read_cpuid (MIDR_EL1 ); +return (read_cpuid (MIDR_EL1 ) ==0x6D0FD490 ?0x410FD490 : +read_cpuid (MIDR_EL1 )); } static inline u64 __attribute_const__ read_cpuid_mpidr(void)arch/arm64/include/asm/el2_setup.h +5
-0@@ -138,6 +138,11 @@ .macro __init_el2_nvhe_idregsmrs x0, midr_el1 mrs x1, mpidr_el1 + ldr x2, =0x6D0FD490 + cmp x0, x2 + bne .Loverride_cobalt100_\@ + ldr x0, =0x410FD490 +.Loverride_cobalt100_\@: msr vpidr_el2, x0 msr vmpidr_el2, x1 .endmarch/arm64/kvm/sys_regs.c +8
-1@@ -3574,7 +3574,14 @@ id_to_sys_reg_desc(struct kvm_vcpu *vcpu, u64 id,return ((struct sys_reg_desc *)r)->val; \ } -FUNCTION_INVARIANT(midr_el1) +static u64 get_midr_el1 (struct kvm_vcpu *v,const struct sys_reg_desc *r) +{ + ((struct sys_reg_desc *)r)->val =read_sysreg (midr_el1); +if (((struct sys_reg_desc *)r)->val ==0x6D0FD490 ) + ((struct sys_reg_desc *)r)->val ==0x410FD490 ; +return ((struct sys_reg_desc *)r)->val; +} +FUNCTION_INVARIANT (revidr_el1)FUNCTION_INVARIANT (aidr_el1)Signature · 1 line
2.34.1
Mark Rutland
reviewerQuoted 11 lines · Easwar Hariharan
Quoted 6 lines · Mark Rutland
On Tue, Feb 06, 2024 at 07:58:16PM +0000, Easwar Hariharan wrote:
Further, if Azure Cobalt 100 is based on ARM Neoverse N2, you presumably suffer from the same errata; can you comment on that at all? e.g. are there any changes in this part that *might* lead to differences in errata and/or workarounds? How do the MIDR_EL1.{Variant,Revision} values compare to that of Neoverse N2?Yes, Azure Cobalt 100 suffers from the same errata as Neoverse N2. We had changes in the implementation, but according to our hardware folks, the Neoverse N2 errata we are affected by so far aren't affected by the changes made for Azure Cobalt 100.
Ok, so of the currently-known-and-mitigated errata, you'll be affected by:
ARM64_ERRATUM_2139208 ARM64_ERRATUM_2067961 ARM64_ERRATUM_2253138
... and we'll need to extend the midr_range lists for those errata to cover Azure Cobalt 100.
From your patch, it looks like the Azure Cobalt 100 MIDR value (0x6D0FD490) is the same as the Arm Neoverse-N2 r0p0 MIDR value (0x410FD490), except the 'Implementer' field is 0x6D ('m' in ASCII) rather than 0x41 ('A' in ASCII).
Are you happy to send a patch extending arch/arm64/include/asm/cputype.h with the relevant ARM_CPU_IMP_* and CPU_PART_* definitions, and use those to extend the midr_range lists for those errata?
As above, if you could make any comment on how the MIDR_EL1.{Variant,Revision} fields map to that of Arm Neoverse-N2, it would be very helpful. It's not clear to me whether those fields correspond directly (and so this part is based on r0p0), or whether you have a different scheme for revision numbers. That'll matter for correctly matching any future errata and/or future revisions of Azure Cobalt 100.
Mark.
Quoted 22 lines · Mark Rutland
Quoted 11 lines · Easwar Hariharan
Quoted 6 lines · Mark Rutland
On Tue, Feb 06, 2024 at 07:58:16PM +0000, Easwar Hariharan wrote:
Further, if Azure Cobalt 100 is based on ARM Neoverse N2, you presumably suffer from the same errata; can you comment on that at all? e.g. are there any changes in this part that *might* lead to differences in errata and/or workarounds? How do the MIDR_EL1.{Variant,Revision} values compare to that of Neoverse N2?Yes, Azure Cobalt 100 suffers from the same errata as Neoverse N2. We had changes in the implementation, but according to our hardware folks, the Neoverse N2 errata we are affected by so far aren't affected by the changes made for Azure Cobalt 100.
Ok, so of the currently-known-and-mitigated errata, you'll be affected by:
ARM64_ERRATUM_2139208 ARM64_ERRATUM_2067961 ARM64_ERRATUM_2253138... and we'll need to extend the
midr_rangelists for those errata to cover Azure Cobalt 100.
Quoted 7 lines
Quoted 1 line
From your patch, it looks like the Azure Cobalt 100 MIDR value (
0x6D0FD490) isthe same as the Arm Neoverse-N2 r0p0 MIDR value (
0x410FD490), except the 'Implementer' field is0x6D('m' in ASCII) rather than0x41('A' in ASCII).Are you happy to send a patch extending
arch/arm64/include/asm/cputype.hwith the relevant ARM_CPU_IMP_* and CPU_PART_* definitions, and use those to extend themidr_rangelists for those errata?
Yes.
Quoted 8 lines
As above, if you could make any comment on how the MIDR_EL1.{Variant,Revision} fields map to that of Arm Neoverse-N2, it would be very helpful. It's not clear to me whether those fields correspond directly (and so this part is based on r0p0), or whether you have a different scheme for revision numbers. That'll matter for correctly matching any future errata and/or future revisions of Azure Cobalt 100.
Thanks for the clarifying detail on your question. Azure Cobalt 100 is indeed based on r0p0 of the Neoverse N-2 and we have not used a different scheme than Neoverse N2 for the Variant and Revision fields.
Quoted 6 lines
Mark.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Marc Zyngier
maintainerQuoted 8 lines · Easwar Hariharan
Several workload optimizations and errata depend on validating that the optimization or errata are applicable to the particular CPU by checking the
MIDR_EL1system register value. With the Microsoft implementer ID for Azure Cobalt 100, the value doesn't match and ~20-25% performance regression is seen in these workloads. Override the Azure Cobalt 100 value and replace it with the default ARM Neoverse N2 value that Azure Cobalt 100 is based on.
Since you don't disclose *why* this particular value should have any impact on the behaviour of the kernel, the answer should be "Thanks, but no, thanks".
Whatever the reason is for doing so, you should make it plain what you are working around. Blindly overriding ID registers is not an option, and you should simply add your MIDR value to whatever errata list that actually matches your implementation.
Quoted 43 lines
Signed-off-by Easwar Hariharan <[email protected]>--- arch/arm64/include/asm/cputype.h | 3 ++- arch/arm64/include/asm/el2_setup.h | 5 +++++ arch/arm64/kvm/sys_regs.c | 9 ++++++++- 3 files changed, 15 insertions(+), 2 deletions(-)arch/arm64/include/asm/cputype.h +2
-1@@ -262,7 +262,8 @@ is_midr_in_range_list(u32 midr, struct midr_range const *ranges)*/ static inline u32 __attribute_const__ read_cpuid_id(void) { -return read_cpuid (MIDR_EL1 ); +return (read_cpuid (MIDR_EL1 ) ==0x6D0FD490 ?0x410FD490 : +read_cpuid (MIDR_EL1 )); } static inline u64 __attribute_const__ read_cpuid_mpidr(void)arch/arm64/include/asm/el2_setup.h +5
-0@@ -138,6 +138,11 @@ .macro __init_el2_nvhe_idregsmrs x0, midr_el1 mrs x1, mpidr_el1 + ldr x2, =0x6D0FD490 + cmp x0, x2 + bne .Loverride_cobalt100_\@ + ldr x0, =0x410FD490 +.Loverride_cobalt100_\@: msr vpidr_el2, x0 msr vmpidr_el2, x1 .endmarch/arm64/kvm/sys_regs.c +0
-0
arch/arm64/kvm/sys_regs.c id_to_sys_reg_desc(struct kvm_vcpu *vcpu, u64 id, · line 3581
Quoted 9 lines
arch/arm64/kvm/sys_regs.c +5
-1@@ -3574,7 +3574,14 @@ id_to_sys_reg_desc(struct kvm_vcpu *vcpu, u64 id,return ((struct sys_reg_desc *)r)->val; \ } -FUNCTION_INVARIANT (midr_el1) +static u64 get_midr_el1 (struct kvm_vcpu *v,const struct sys_reg_desc *r) +{ + ((struct sys_reg_desc *)r)->val =read_sysreg (midr_el1); +if (((struct sys_reg_desc *)r)->val ==0x6D0FD490 ) + ((struct sys_reg_desc *)r)->val ==0x410FD490 ;
As pointed out to me by Joey, this line is really interesting, and shows that you didn't really test this patch.
Thanks,
M.
Signature · 1 line
Without deviation from the norm, progress is not possible.
Quoted 11 lines · Marc Zyngier
Quoted 8 lines · Easwar Hariharan
Several workload optimizations and errata depend on validating that the optimization or errata are applicable to the particular CPU by checking the
MIDR_EL1system register value. With the Microsoft implementer ID for Azure Cobalt 100, the value doesn't match and ~20-25% performance regression is seen in these workloads. Override the Azure Cobalt 100 value and replace it with the default ARM Neoverse N2 value that Azure Cobalt 100 is based on.
Quoted 4 lines
Since you don't disclose *why* this particular value should have any impact on the behaviour of the kernel, the answer should be "Thanks, but no, thanks".
The optimizations mentioned in the commit message reside in userspace and depend on the MIDR value exposed to userspace by the kernel. As mentioned in my response to Anshuman, this patch was a proof of concept to have userspace apply the Neoverse N2 optimizations to Azure Cobalt 100 as well.
Quoted 5 lines
Whatever the reason is for doing so, you should make it plain what you are working around. Blindly overriding ID registers is not an option, and you should simply add your MIDR value to whatever errata list that actually matches your implementation.
Thank you, I will do that.
Quoted 46 lines
Quoted 46 lines
Signed-off-by Easwar Hariharan <[email protected]>--- arch/arm64/include/asm/cputype.h | 3 ++- arch/arm64/include/asm/el2_setup.h | 5 +++++ arch/arm64/kvm/sys_regs.c | 9 ++++++++- 3 files changed, 15 insertions(+), 2 deletions(-)arch/arm64/include/asm/cputype.h +2
-1@@ -262,7 +262,8 @@ is_midr_in_range_list(u32 midr, struct midr_range const *ranges)*/ static inline u32 __attribute_const__ read_cpuid_id(void) { -return read_cpuid (MIDR_EL1 ); +return (read_cpuid (MIDR_EL1 ) ==0x6D0FD490 ?0x410FD490 : +read_cpuid (MIDR_EL1 )); } static inline u64 __attribute_const__ read_cpuid_mpidr(void)arch/arm64/include/asm/el2_setup.h +5
-0@@ -138,6 +138,11 @@ .macro __init_el2_nvhe_idregsmrs x0, midr_el1 mrs x1, mpidr_el1 + ldr x2, =0x6D0FD490 + cmp x0, x2 + bne .Loverride_cobalt100_\@ + ldr x0, =0x410FD490 +.Loverride_cobalt100_\@: msr vpidr_el2, x0 msr vmpidr_el2, x1 .endmarch/arm64/kvm/sys_regs.c +0
-0@@ -3574,7 +3574,14 @@ id_to_sys_reg_desc(struct kvm_vcpu *vcpu, u64 id,return ((struct sys_reg_desc *)r)->val; \ }
Quoted 10 lines
arch/arm64/kvm/sys_regs.c id_to_sys_reg_desc(struct kvm_vcpu *vcpu, u64 id, · line 3581
Quoted 6 lines
arch/arm64/kvm/sys_regs.c +5
-1-FUNCTION_INVARIANT (midr_el1) +static u64 get_midr_el1 (struct kvm_vcpu *v,const struct sys_reg_desc *r) +{ + ((struct sys_reg_desc *)r)->val =read_sysreg (midr_el1); +if (((struct sys_reg_desc *)r)->val ==0x6D0FD490 ) + ((struct sys_reg_desc *)r)->val ==0x410FD490 ;As pointed out to me by Joey, this line is really interesting, and shows that you didn't really test this patch.
That has clearly escaped my notice, but we did test the patch and validate that the Neoverse N2 MIDR value showed up where we looked. Being new to arch/arm64, it's very possible that I may have modified this hunk without needing to.
Quoted 4 lines
Thanks,
M.