| Message ID | 1432060414-5195-4-git-send-email-peter.maydell@linaro.org |
|---|---|
| State | Accepted |
| Commit | f2932df777dace044719dc2f394f5a5a8aa1b1cd |
| Headers | show |
On 28 May 2015 at 06:30, Edgar E. Iglesias <edgar.iglesias@xilinx.com> wrote: > On Tue, May 19, 2015 at 07:33:23PM +0100, Peter Maydell wrote: >> If the SCTLR.UMA trap bit is set then attempts by EL0 to update >> the PSTATE DAIF bits via "MSR DAIFSet, imm" and "MSR DAIFClr, imm" >> instructions will raise an exception. We were failing to set >> the syndrome information for this exception, which meant that >> it would be reported as a repeat of whatever the previous >> exception was. Set the correct syndrome information. >> --- >> target-arm/op_helper.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c >> index 43e3457..5af4a0e 100644 >> --- a/target-arm/op_helper.c >> +++ b/target-arm/op_helper.c >> @@ -381,6 +381,9 @@ void HELPER(msr_i_pstate)(CPUARMState *env, uint32_t op, uint32_t imm) >> */ >> if (arm_current_el(env) == 0 && !(env->cp15.sctlr_el[1] & SCTLR_UMA)) { >> env->exception.target_el = exception_target_el(env); >> + env->exception.syndrome = syn_aa64_sysregtrap(0, extract32(op, 0, 3), >> + extract32(op, 3, 3), 4, >> + 0x1f, imm, 0); > > Did you possibly reverse the argument order of 0x1f and imm? Ah, you're right; I was confused because the argument order of our syn_aa64_sysregtrap() and the pseudocode AArch64.SystemRegisterTrap is different (the latter follows the field order in the syndrome register and ours doesn't). -- PMM
On 28 May 2015 at 09:30, Peter Maydell <peter.maydell@linaro.org> wrote: > On 28 May 2015 at 06:30, Edgar E. Iglesias <edgar.iglesias@xilinx.com> wrote: >>> @@ -381,6 +381,9 @@ void HELPER(msr_i_pstate)(CPUARMState *env, uint32_t op, uint32_t imm) >>> */ >>> if (arm_current_el(env) == 0 && !(env->cp15.sctlr_el[1] & SCTLR_UMA)) { >>> env->exception.target_el = exception_target_el(env); >>> + env->exception.syndrome = syn_aa64_sysregtrap(0, extract32(op, 0, 3), >>> + extract32(op, 3, 3), 4, >>> + 0x1f, imm, 0); >> >> Did you possibly reverse the argument order of 0x1f and imm? > > Ah, you're right; I was confused because the argument order of our > syn_aa64_sysregtrap() and the pseudocode AArch64.SystemRegisterTrap > is different (the latter follows the field order in the syndrome > register and ours doesn't). I also managed to forget the signoff: Signed-off-by: Peter Maydell <peter.maydell@linaro.org> If this is the only fix in this series (I think you have one or two patches still left to review) then I propose to add it as I put the patches in target-arm.next: - 0x1f, imm, 0); + imm, 0x1f, 0); thanks -- PMM
On 28 May 2015 at 12:44, Edgar E. Iglesias <edgar.iglesias@xilinx.com> wrote: > One of the patches had a missing target_el assigment for > CP_ACCESS_TRAP_UNCATEGORIZED that I commented on a while back. That's fixed in this series, I think. Patches in this series I don't think I've seen a review or ack for: target-arm: Allow cp access functions to indicate traps to EL2 or EL3 target-arm: Add AArch64 CPTR registers target-arm: Extend FP checks to use an EL thanks -- PMM
diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c index 43e3457..5af4a0e 100644 --- a/target-arm/op_helper.c +++ b/target-arm/op_helper.c @@ -381,6 +381,9 @@ void HELPER(msr_i_pstate)(CPUARMState *env, uint32_t op, uint32_t imm) */ if (arm_current_el(env) == 0 && !(env->cp15.sctlr_el[1] & SCTLR_UMA)) { env->exception.target_el = exception_target_el(env); + env->exception.syndrome = syn_aa64_sysregtrap(0, extract32(op, 0, 3), + extract32(op, 3, 3), 4, + 0x1f, imm, 0); raise_exception(env, EXCP_UDEF); }