* [Qemu-devel] [PATCH] target/arm: Fix register definitions for VMIDR and VMPIDR
@ 2018-02-15 18:24 Peter Maydell
2018-02-16 13:25 ` [Qemu-devel] [Qemu-arm] " Philippe Mathieu-Daudé
0 siblings, 1 reply; 2+ messages in thread
From: Peter Maydell @ 2018-02-15 18:24 UTC (permalink / raw)
To: qemu-arm, qemu-devel; +Cc: patches
The register definitions for VMIDR and VMPIDR have separate
reginfo structs for the AArch32 and AArch64 registers. However
the 32-bit versions are wrong:
* they use offsetof instead of offsetoflow32 to mark where
the 32-bit value lives in the uint64_t CPU state field
* they don't mark themselves as ARM_CP_ALIAS
In particular this means that if you try to use an Arm guest CPU
which enables EL2 on a big-endian host it will assert at reset:
target/arm/cpu.c:114: cp_reg_check_reset: Assertion `oldvalue == newvalue' failed.
because the reset of the 32-bit register writes to the top
half of the uint64_t.
Correct the errors in the structures.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
This is necessary for 'make check' to pass on big endian
systems with the 'raspi3' board enabled, which is the
first board which has an EL2-enabled-by-default CPU.
---
target/arm/helper.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index e7586fcf6c..e27957df38 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -5068,8 +5068,8 @@ void register_cp_regs_for_features(ARMCPU *cpu)
{ .name = "VPIDR", .state = ARM_CP_STATE_AA32,
.cp = 15, .opc1 = 4, .crn = 0, .crm = 0, .opc2 = 0,
.access = PL2_RW, .accessfn = access_el3_aa32ns,
- .resetvalue = cpu->midr,
- .fieldoffset = offsetof(CPUARMState, cp15.vpidr_el2) },
+ .resetvalue = cpu->midr, .type = ARM_CP_ALIAS,
+ .fieldoffset = offsetoflow32(CPUARMState, cp15.vpidr_el2) },
{ .name = "VPIDR_EL2", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 4, .crn = 0, .crm = 0, .opc2 = 0,
.access = PL2_RW, .resetvalue = cpu->midr,
@@ -5077,8 +5077,8 @@ void register_cp_regs_for_features(ARMCPU *cpu)
{ .name = "VMPIDR", .state = ARM_CP_STATE_AA32,
.cp = 15, .opc1 = 4, .crn = 0, .crm = 0, .opc2 = 5,
.access = PL2_RW, .accessfn = access_el3_aa32ns,
- .resetvalue = vmpidr_def,
- .fieldoffset = offsetof(CPUARMState, cp15.vmpidr_el2) },
+ .resetvalue = vmpidr_def, .type = ARM_CP_ALIAS,
+ .fieldoffset = offsetoflow32(CPUARMState, cp15.vmpidr_el2) },
{ .name = "VMPIDR_EL2", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 4, .crn = 0, .crm = 0, .opc2 = 5,
.access = PL2_RW,
--
2.16.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [Qemu-devel] [Qemu-arm] [PATCH] target/arm: Fix register definitions for VMIDR and VMPIDR
2018-02-15 18:24 [Qemu-devel] [PATCH] target/arm: Fix register definitions for VMIDR and VMPIDR Peter Maydell
@ 2018-02-16 13:25 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 2+ messages in thread
From: Philippe Mathieu-Daudé @ 2018-02-16 13:25 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel; +Cc: patches
On 02/15/2018 03:24 PM, Peter Maydell wrote:
> The register definitions for VMIDR and VMPIDR have separate
> reginfo structs for the AArch32 and AArch64 registers. However
> the 32-bit versions are wrong:
> * they use offsetof instead of offsetoflow32 to mark where
> the 32-bit value lives in the uint64_t CPU state field
Maybe we can replace all offsetof() by offsetof64() and forbid the use
of offsetof() in this file, this will make A32 endian/alignment errors
more apparent.
> * they don't mark themselves as ARM_CP_ALIAS
>
> In particular this means that if you try to use an Arm guest CPU
> which enables EL2 on a big-endian host it will assert at reset:
> target/arm/cpu.c:114: cp_reg_check_reset: Assertion `oldvalue == newvalue' failed.
>
> because the reset of the 32-bit register writes to the top
> half of the uint64_t.
>
> Correct the errors in the structures.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> This is necessary for 'make check' to pass on big endian
> systems with the 'raspi3' board enabled, which is the
> first board which has an EL2-enabled-by-default CPU.
> ---
> target/arm/helper.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index e7586fcf6c..e27957df38 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -5068,8 +5068,8 @@ void register_cp_regs_for_features(ARMCPU *cpu)
> { .name = "VPIDR", .state = ARM_CP_STATE_AA32,
> .cp = 15, .opc1 = 4, .crn = 0, .crm = 0, .opc2 = 0,
> .access = PL2_RW, .accessfn = access_el3_aa32ns,
> - .resetvalue = cpu->midr,
> - .fieldoffset = offsetof(CPUARMState, cp15.vpidr_el2) },
> + .resetvalue = cpu->midr, .type = ARM_CP_ALIAS,
> + .fieldoffset = offsetoflow32(CPUARMState, cp15.vpidr_el2) },
> { .name = "VPIDR_EL2", .state = ARM_CP_STATE_AA64,
> .opc0 = 3, .opc1 = 4, .crn = 0, .crm = 0, .opc2 = 0,
> .access = PL2_RW, .resetvalue = cpu->midr,
> @@ -5077,8 +5077,8 @@ void register_cp_regs_for_features(ARMCPU *cpu)
> { .name = "VMPIDR", .state = ARM_CP_STATE_AA32,
> .cp = 15, .opc1 = 4, .crn = 0, .crm = 0, .opc2 = 5,
> .access = PL2_RW, .accessfn = access_el3_aa32ns,
> - .resetvalue = vmpidr_def,
> - .fieldoffset = offsetof(CPUARMState, cp15.vmpidr_el2) },
> + .resetvalue = vmpidr_def, .type = ARM_CP_ALIAS,
> + .fieldoffset = offsetoflow32(CPUARMState, cp15.vmpidr_el2) },
> { .name = "VMPIDR_EL2", .state = ARM_CP_STATE_AA64,
> .opc0 = 3, .opc1 = 4, .crn = 0, .crm = 0, .opc2 = 5,
> .access = PL2_RW,
>
After enjoying scrolling a 6666p specs,
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-02-16 13:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-15 18:24 [Qemu-devel] [PATCH] target/arm: Fix register definitions for VMIDR and VMPIDR Peter Maydell
2018-02-16 13:25 ` [Qemu-devel] [Qemu-arm] " Philippe Mathieu-Daudé
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).