The architecture requires (R_TYTWB) that an attempt to return from EL3
when SCR_EL3.{NSE,NS} are {1,0} is an illegal exception return. (This
enforces that the CPU can't ever be executing below EL3 with the
NSE,NS bits indicating an invalid security state.)
We were missing this check; a
On 8/7/23 08:06, Peter Maydell wrote:
The architecture requires (R_TYTWB) that an attempt to return from EL3
when SCR_EL3.{NSE,NS} are {1,0} is an illegal exception return. (This
enforces that the CPU can't ever be executing below EL3 with the
NSE,NS bits indicating an invalid security
The architecture requires (R_TYTWB) that an attempt to return from EL3
when SCR_EL3.{NSE,NS} are {1,0} is an illegal exception return. (This
enforces that the CPU can't ever be executing below EL3 with the
NSE,NS bits indicating an invalid security state.)
We were missing this check; a
From: LIU Zhiwei
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Message-id: 20220120122050.41546-3-zhiwei_...@c-sky.com
Signed-off-by: Alistair Francis
---
target
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
target/riscv/helper.h | 4 ++--
target/riscv/insn_trans/trans_privileged.c.inc | 7
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
target/riscv/helper.h | 4 ++--
target/riscv/insn_trans/trans_privileged.c.inc | 7
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
target/riscv/helper.h | 4 ++--
target/riscv/insn_trans/trans_privileged.c.inc | 7
38d R01= R02=7004938c R03=
>> > > R04=7005e410 R05=10020000 R06=e000eda0 R07=
>> > > R08=0010 R09=1003f8e0 R10=e000ed94 R11=
>> > > R12= R13=1003dbe0 R14=fff9 R15=7004e794
>> > > XPSR=0103 --
: 0x7f4faa471100 [/7004e794/0x312000c1] Hal_MemFault
> > > R00=7004938d R01= R02=7004938c R03=
> > > R04=7005e410 R05=1002 R06=e000eda0 R07=
> > > R08=0010 R09=1003f8e0 R10=e000ed94 R11=
> > > R12=ffff R13=1003dbe
On Thu, 16 Dec 2021 at 20:07, abhijeet inamdar
wrote:
>
> If I won't make that change it gives me immediate error as follows:
>
> Taking exception 18 [v7M INVSTATE UsageFault]
> ...BusFault with BFSR.STKERR
> ...taking pending nonsecure exception 3
> qemu: fatal: Lockup: can't take terminal derive
4=7005e410 R05=1002 R06=e000eda0 R07=
> > R08=0010 R09=1003f8e0 R10=e000ed94 R11=
> > R12= R13=1003dbe0 R14=fff9 R15=7004e794
> > XPSR=0103 T handler
> > Taking exception 8 [QEMU v7M exception exit]
> > Exception return: magi
e0 R14=fff9 R15=7004e794
> XPSR=0103 T handler
> Taking exception 8 [QEMU v7M exception exit]
> Exception return: magic PC fff9 previous exception 3
> M profile return from interrupt with misaligned PC is UNPREDICTABLE on v7M
> ...successful exception return
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
target/riscv/helper.h | 4 ++--
target/riscv/insn_trans/trans_privileged.c.inc | 7
On Fri, Nov 12, 2021 at 1:54 AM LIU Zhiwei wrote:
>
> As pc will be written by the xepc in exception return, just ignore
> pc in translation.
>
> Signed-off-by: LIU Zhiwei
> Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
>
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
Reviewed-by: Richard Henderson
---
target/riscv/helper.h | 4 ++--
target/riscv/insn_trans/trans_privileged.c.inc | 7 ++-
target/riscv/op_helper.c
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
Reviewed-by: Richard Henderson
---
target/riscv/helper.h | 4 ++--
target/riscv/insn_trans/trans_privileged.c.inc | 7 ++-
target/riscv/op_helper.c
On 11/10/21 8:04 AM, LIU Zhiwei wrote:
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
Reviewed-by: Richard Henderson
---
target/riscv/helper.h | 4 ++--
target/riscv/insn_trans/trans_privileged.c.inc
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
Reviewed-by: Richard Henderson
---
target/riscv/helper.h | 4 ++--
target/riscv/insn_trans/trans_privileged.c.inc | 7 ++-
target/riscv/op_helper.c
We only have to process the special CSRs(like vtype/misa) when xlen
changes, according to the explicitly specified behavior about the CSR
width change behavior.
For normal CSRs, the default behavior in section 2.4 , CSR Width
Modulation, is enough.
And if we split the vill out, we will never
We only have to process the special CSRs(like vtype/misa) when xlen
changes, according to the explicitly specified behavior about the CSR
width change behavior.
For normal CSRs, the default behavior in section 2.4 , CSR Width
Modulation, is enough.
And if we split the vill out, we will never
On 2021/11/2 上午12:43, Richard Henderson wrote:
On 11/1/21 6:01 AM, LIU Zhiwei wrote:
After excpetion return, we should give a xlen view of context in new
priveledge, including the general registers, pc, and CSRs.
Signed-off-by: LIU Zhiwei
---
target/riscv/helper.h |
On 11/1/21 6:01 AM, LIU Zhiwei wrote:
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
---
target/riscv/helper.h | 4 ++--
target/riscv/insn_trans/trans_privileged.c.inc | 7 ++-
target/riscv
On 11/1/21 6:01 AM, LIU Zhiwei wrote:
After excpetion return, we should give a xlen view of context in new
priveledge, including the general registers, pc, and CSRs.
Signed-off-by: LIU Zhiwei
---
target/riscv/helper.h | 1 +
.../riscv/insn_trans/trans_privileged.c.in
As pc will be written by the xepc in exception return, just ignore
pc in translation.
Signed-off-by: LIU Zhiwei
---
target/riscv/helper.h | 4 ++--
target/riscv/insn_trans/trans_privileged.c.inc | 7 ++-
target/riscv/op_helper.c | 4 ++--
3
After excpetion return, we should give a xlen view of context in new
priveledge, including the general registers, pc, and CSRs.
Signed-off-by: LIU Zhiwei
---
target/riscv/helper.h | 1 +
.../riscv/insn_trans/trans_privileged.c.inc | 2 ++
target/riscv/op_helper.c
When an M-profile CPU is restoring registers from the stack on
exception return, the stack pointer to use is determined based on
bits in the magic exception return type value. We were not getting
this logic entirely correct.
Whether we use one of the Secure stack pointers or one of the
Non
On 5/20/21 6:09 AM, Peter Maydell wrote:
When an M-profile CPU is restoring registers from the stack on
exception return, the stack pointer to use is determined based on
bits in the magic exception return type value. We were not getting
this logic entirely correct.
Whether we use one of the
When an M-profile CPU is restoring registers from the stack on
exception return, the stack pointer to use is determined based on
bits in the magic exception return type value. We were not getting
this logic entirely correct.
Whether we use one of the Secure stack pointers or one of the
Non
In v8.1M a new exception return check is added which may cause a NOCP
UsageFault (see rule R_XLTP): before we clear s0..s15 and the FPSCR
we must check whether access to CP10 from the Security state of the
returning exception is disabled; if it is then we must take a fault.
(Note that for our
On 11/19/20 3:56 PM, Peter Maydell wrote:
> In v8.1M a new exception return check is added which may cause a NOCP
> UsageFault (see rule R_XLTP): before we clear s0..s15 and the FPSCR
> we must check whether access to CP10 from the Security state of the
> returning exception is disabl
In v8.1M a new exception return check is added which may cause a NOCP
UsageFault (see rule R_XLTP): before we clear s0..s15 and the FPSCR
we must check whether access to CP10 from the Security state of the
returning exception is disabled; if it is then we must take a fault.
(Note that for our
From: Peter Maydell
An attempt to do an exception-return (branch to one of the magic
addresses) in linux-user mode for M-profile should behave like
a normal branch, because linux-user mode is always going to be
in 'handler' mode. This used to work, but we broke it when we added
support
From: Peter Maydell
An attempt to do an exception-return (branch to one of the magic
addresses) in linux-user mode for M-profile should behave like
a normal branch, because linux-user mode is always going to be
in 'handler' mode. This used to work, but we broke it when we added
support
An attempt to do an exception-return (branch to one of the magic
addresses) in linux-user mode for M-profile should behave like
a normal branch, because linux-user mode is always going to be
in 'handler' mode. This used to work, but we broke it when we added
support for the M-profil
On 8/22/19 6:15 AM, Peter Maydell wrote:
> The upshot of all this is that for linux-user mode we should never
> do any of the bx_excret magic, so the code change is simple.
>
> This ought to be a weird corner case that only affects broken guest
> code (because Linux user processes should never be
An attempt to do an exception-return (branch to one of the magic
addresses) in linux-user mode for M-profile should behave like
a normal branch, because linux-user mode is always going to be
in 'handler' mode. This used to work, but we broke it when we added
support for the M-profil
Handle floating point registers in exception return.
This corresponds to pseudocode functions ValidateExceptionReturn(),
ExceptionReturn(), PopStack() and ConsumeExcStackFrame().
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190416125744.27770-16-peter.mayd
On 4/16/19 5:57 AM, Peter Maydell wrote:
> Handle floating point registers in exception return.
> This corresponds to pseudocode functions ValidateExceptionReturn(),
> ExceptionReturn(), PopStack() and ConsumeExcStackFrame().
>
> Signed-off-by: Peter Maydell
> ---
> targ
Handle floating point registers in exception return.
This corresponds to pseudocode functions ValidateExceptionReturn(),
ExceptionReturn(), PopStack() and ConsumeExcStackFrame().
Signed-off-by: Peter Maydell
---
target/arm/helper.c | 142 +++-
1 file
From: Richard Henderson
Found by inspection: Rn is the base register against which the
load began; I is the register within the mask being processed.
The exception return should of course be processed from the loaded PC.
Signed-off-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
On Sat, 2 Mar 2019 at 19:10, Philippe Mathieu-Daudé wrote:
>
> On 3/1/19 9:29 PM, Richard Henderson wrote:
> > Found by inspection: Rn is the base register against which the
> > load began; I is the register within the mask being processed.
> > The exception return shou
On 3/1/19 9:29 PM, Richard Henderson wrote:
> Found by inspection: Rn is the base register against which the
> load began; I is the register within the mask being processed.
> The exception return should of course be procesed from the loaded PC.
"processed"
>
> Signed-
Found by inspection: Rn is the base register against which the
load began; I is the register within the mask being processed.
The exception return should of course be procesed from the loaded PC.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 2 +-
1 file changed, 1 insertion
From: Alexander Graf
In U-boot, we switch from S-SVC -> Mon -> Hyp mode when we want to
enter Hyp mode. The change into Hyp mode is done by doing an
exception return from Mon. This doesn't work with current QEMU.
The problem is that in bad_mode_switch() we refuse to allow
the cha
For AArch32, exception return happens through certain kinds
of CPSR write. We don't currently have any CPU_LOG_INT logging
of these events (unlike AArch64, where we log in the ERET
instruction). Add some suitable logging.
This will log exception returns like this:
Exception return from AA
On 10/12/18 7:42 AM, Peter Maydell wrote:
> For AArch32, exception return happens through certain kinds
> of CPSR write. We don't currently have any CPU_LOG_INT logging
> of these events (unlike AArch64, where we log in the ERET
> instruction). Add some suitable logging.
&
For AArch32, exception return happens through certain kinds
of CPSR write. We don't currently have any CPU_LOG_INT logging
of these events (unlike AArch64, where we log in the ERET
instruction). Add some suitable logging.
This will log exception returns like this:
Exception return from AA
On 9 July 2018 at 15:30, Richard Henderson wrote:
> On 07/09/2018 05:45 AM, Peter Maydell wrote:
>> For M-profile exception returns, the mmu index to use for exception
>> return unstacking is supposed to be that of wherever we are returning to:
>> * if returning to han
On 07/09/2018 05:45 AM, Peter Maydell wrote:
> For M-profile exception returns, the mmu index to use for exception
> return unstacking is supposed to be that of wherever we are returning to:
> * if returning to handler mode, privileged
> * if returning to thread mode, privileged or
For M-profile exception returns, the mmu index to use for exception
return unstacking is supposed to be that of wherever we are returning to:
* if returning to handler mode, privileged
* if returning to thread mode, privileged or unprivileged depending on
CONTROL.nPRIV for the destination
Currently our M profile exception return code switches to the
target stack pointer relatively early in the process, before
it tries to pop the exception frame off the stack. This is
awkward for v8M for two reasons:
* in v8M the process vs main stack pointer is not selected
purely by the value
Now that we can handle the CONTROL.SPSEL bit not necessarily being
in sync with the current stack pointer, we can restore the correct
security state on exception return. This happens before we start
to read registers off the stack frame, but after we have taken
possible usage faults for bad
In the v8M architecture, return from an exception to a PC which
has bit 0 set is not UNPREDICTABLE; it is defined that bit 0
is discarded [R_HRJH]. Restrict our complaint about this to v7M.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-i
On exception return for v8M, the SPSEL bit in the EXC_RETURN magic
value should be restored to the SPSEL bit in the CONTROL register
banked specified by the EXC_RETURN.ES bit.
Add write_v7m_control_spsel_for_secstate() which behaves like
write_v7m_control_spsel() but allows the caller to specify
; this is because we also use this
> * function in handling of pushing of the callee-saves registers
> * part of the v8M stack frame (pseudocode PushCalleeStack()),
> * and in the tailchain codepath the SPSEL bit comes from the exception
> * return magic LR value fro
n the
>>> + * SPSEL control bit value; this is because we also use this
>>> + * function in handling of pushing of the callee-saves registers
>>> + * part of the v8M stack frame, and in that case the SPSEL bit
>>> + * comes from the exception return
On 10/05/2017 12:32 PM, Richard Henderson wrote:
> if (env->regs[15] & 1) {
> if (!arm_feature(env, ARM_FEATURE_V8)) {
> qemu_log_mask(...);
> }
> env->regs[15] &= ~1U;
> }
Bah. Even better to move the bit clear statement before the feature check.
The t
On 09/22/2017 10:59 AM, Peter Maydell wrote:
> +if ((env->regs[15] & 1) && !arm_feature(env, ARM_FEATURE_V8)) {
> qemu_log_mask(LOG_GUEST_ERROR,
>"M profile return from interrupt with misaligned "
> - "PC is UNPREDICTABLE\n")
On 5 October 2017 at 17:04, Richard Henderson
wrote:
> On 09/22/2017 10:59 AM, Peter Maydell wrote:
>> Currently our M profile exception return code switches to the
>> target stack pointer relatively early in the process, before
>> it tries to pop the exception frame o
On 09/22/2017 10:59 AM, Peter Maydell wrote:
> On exception return for v8M, the SPSEL bit in the EXC_RETURN magic
> value should be restored to the SPSEL bit in the CONTROL register
> banked specified by the EXC_RETURN.ES bit.
>
> Add write_v7m_control_spsel_for_secstate() whi
On 09/22/2017 10:59 AM, Peter Maydell wrote:
> Now that we can handle the CONTROL.SPSEL bit not necessarily being
> in sync with the current stack pointer, we can restore the correct
> security state on exception return. This happens before we start
> to read registers off the stac
On 09/22/2017 10:59 AM, Peter Maydell wrote:
> Currently our M profile exception return code switches to the
> target stack pointer relatively early in the process, before
> it tries to pop the exception frame off the stack. This is
> awkward for v8M for two reasons:
> * in v8M
On 09/22/2017 11:59 AM, Peter Maydell wrote:
> Currently our M profile exception return code switches to the
> target stack pointer relatively early in the process, before
> it tries to pop the exception frame off the stack. This is
> awkward for v8M for two reasons:
> * in v8M
On exception return for v8M, the SPSEL bit in the EXC_RETURN magic
value should be restored to the SPSEL bit in the CONTROL register
banked specified by the EXC_RETURN.ES bit.
Add write_v7m_control_spsel_for_secstate() which behaves like
write_v7m_control_spsel() but allows the caller to specify
Currently our M profile exception return code switches to the
target stack pointer relatively early in the process, before
it tries to pop the exception frame off the stack. This is
awkward for v8M for two reasons:
* in v8M the process vs main stack pointer is not selected
purely by the value
Now that we can handle the CONTROL.SPSEL bit not necessarily being
in sync with the current stack pointer, we can restore the correct
security state on exception return. This happens before we start
to read registers off the stack frame, but after we have taken
possible usage faults for bad
In the v8M architecture, return from an exception to a PC which
has bit 0 set is not UNPREDICTABLE; it is defined that bit 0
is discarded [R_HRJH]. Restrict our complaint about this to v7M.
Signed-off-by: Peter Maydell
---
target/arm/helper.c | 20 +---
1 file changed, 13 inserti
.c b/target/arm/op_helper.c
>> index 2a85666..8222c19 100644
>> --- a/target/arm/op_helper.c
>> +++ b/target/arm/op_helper.c
>> @@ -1027,6 +1027,9 @@ void HELPER(exception_return)(CPUARMState *env)
>> } else {
>> env->regs[15] = env->
1027,9 @@ void HELPER(exception_return)(CPUARMState *env)
> } else {
> env->regs[15] = env->elr_el[cur_el] & ~0x3;
> }
> +
> +env->pc = env->regs[15];
> +
> qemu_log_mask(CPU_LOG_INT, "Exception return from AArch64
..8222c19 100644
--- a/target/arm/op_helper.c
+++ b/target/arm/op_helper.c
@@ -1027,6 +1027,9 @@ void HELPER(exception_return)(CPUARMState *env)
} else {
env->regs[15] = env->elr_el[cur_el] & ~0x3;
}
+
+env->pc = env->regs[15];
+
qemu_log_ma
specially but then catching the attempt to execute from the magic
address value. This is not ideal, because:
* there are guest visible differences from the architecturally
specified behaviour (for instance jumping to 0xFFxx via a
different instruction should not cause an exception return but
Now that we've rewritten M-profile exception return so that the magic
PC values are not visible to other parts of QEMU, we can delete the
special casing of them elsewhere.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-id: 14918
arm: Track M profile handler mode state in TB flags
>> arm: Implement M profile exception return properly
>> arm: Remove workarounds for old M-profile exception return
>> implementation
>>
>> target/arm/cpu.h | 9 +++
&g
t_pc_im() up in the file
arm: Move condition-failed codepath generation out of if()
arm: Abstract out "are we singlestepping" test to utility function
arm: Track M profile handler mode state in TB flags
arm: Implement M profile exception return properly
arm: Remove workarounds fo
Now that we've rewritten M-profile exception return so that the magic
PC values are not visible to other parts of QEMU, we can delete the
special casing of them elsewhere.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/cpu.c
specially but then catching the attempt to execute from the magic
address value. This is not ideal, because:
* there are guest visible differences from the architecturally
specified behaviour (for instance jumping to 0xFFxx via a
different instruction should not cause an exception return but
exception return but it
will in the QEMU implementation)
* we have to account for it in various places (like refusing to take
an interrupt if the PC is at a magic value, and making sure that
the MPU doesn't deny execution at the magic value addresses)
Drop these hacks, and in
ception != 0) in the TB flags and test that here
rather than testing IS_USER.
(Otherwise if you have code which executes the same 'bx' instruction
both as a legitimate exception return and as a fake exception
return while in privileged thread mode then we assert() in
do_v7m_exception_exit.
On 10 April 2017 at 14:52, Philippe Mathieu-Daudé wrote:
> On 04/10/2017 07:39 AM, Peter Maydell wrote:
>> +/* Is the new PC value in the magic range indicating exception
>> return? */
>> +tcg_gen_brcondi_i32(TCG_COND_GEU, cpu_R[15], 0xff00,
>> excret_la
On 04/10/2017 07:39 AM, Peter Maydell wrote:
Now that we've rewritten M-profile exception return so that the magic
PC values are not visible to other parts of QEMU, we can delete the
special casing of them elsewhere.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-
instruction should not cause an exception return but it
will in the QEMU implementation)
* we have to account for it in various places (like refusing to take
an interrupt if the PC is at a magic value, and making sure that
the MPU doesn't deny execution at the magic value addresses)
Drop
but then catching the attempt to execute from the magic
address value. This is not ideal, because:
* there are guest visible differences from the architecturally
specified behaviour (for instance jumping to 0xFFxx via a
different instruction should not cause an exception return but it
ement exception return the way the
architecture specifies -- by having the relevant instructions check
for the magic value and raise the 'do an exception return' QEMU
internal exception immediately.
I realised when I was looking at the MPU patches that the current
mechanism was a bit awk
Now that we've rewritten M-profile exception return so that the magic
PC values are not visible to other parts of QEMU, we can delete the
special casing of them elsewhere.
Signed-off-by: Peter Maydell
---
target/arm/cpu.c | 43 ++-
targe
Implement the exception return consistency checks
described in the v7M pseudocode ExceptionReturn().
Inspired by a patch from Michael Davidsaver's series, but
this is a reimplementation from scratch based on the
ARM ARM pseudocode.
Signed-off-by: Peter Maydell
Reviewed-by: Alex B
Peter Maydell writes:
> Implement the exception return consistency checks
> described in the v7M pseudocode ExceptionReturn().
>
> Inspired by a patch from Michael Davidsaver's series, but
> this is a reimplementation from scratch based on the
> ARM ARM pseudocode.
&
Implement the exception return consistency checks
described in the v7M pseudocode ExceptionReturn().
Inspired by a patch from Michael Davidsaver's series, but
this is a reimplementation from scratch based on the
ARM ARM pseudocode.
Signed-off-by: Peter Maydell
---
target/arm/cpu.h
Peter Maydell writes:
> On 14 October 2016 at 16:13, Alex Bennée wrote:
>> This was broken by the fix for 9b6a3ea7a699594162ed3d11e4e04b98568dc5c0.
>> Specifically a movs pc,lr in the kernels ret_fast_syscall returning to
>> some thumb mode user space code but store_reg unconditionally aligned
On 14 October 2016 at 16:13, Alex Bennée wrote:
> I suspect we need to audit all calls to store_reg that might involve the
> PC to ensure "interworking" branches are correctly handled. Also I'm not
> quite sure how the code worked before 9b6a3e as the store_reg path
> wouldn't have triggered the s
On 14 October 2016 at 16:13, Alex Bennée wrote:
> This was broken by the fix for 9b6a3ea7a699594162ed3d11e4e04b98568dc5c0.
> Specifically a movs pc,lr in the kernels ret_fast_syscall returning to
> some thumb mode user space code but store_reg unconditionally aligned
> the return PC instead of tre
This was broken by the fix for 9b6a3ea7a699594162ed3d11e4e04b98568dc5c0.
Specifically a movs pc,lr in the kernels ret_fast_syscall returning to
some thumb mode user space code but store_reg unconditionally aligned
the return PC instead of treating the return as an "interworking"
branch.
I suspect
On 19 April 2016 at 19:07, Sergey Sorokin wrote:
> In AArch32 instruction ADDS r15, ... is used for exception return.
>
> Signed-off-by: Sergey Sorokin
> ---
> target-arm/translate.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git
On 19 April 2016 at 19:07, Sergey Sorokin wrote:
> There is a duplicating code in AArch32 exception return implementation.
> The patch rearranges the code to avoid this.
>
> Signed-off-by: Sergey Sorokin
> ---
> target-arm/translate.c | 36 +---
There is a duplicating code in AArch32 exception return implementation.
The patch rearranges the code to avoid this.
Signed-off-by: Sergey Sorokin
---
target-arm/translate.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/target-arm
There is a duplicating code in AArch32 exception return implementation.
Also there is a missed exception return on AArch32 instruction ADDS r15.
The patches rearrange the code and fix these issues.
Sergey Sorokin (2):
target-arm: Unify AArch32 exception return generating functions
target-arm
In AArch32 instruction ADDS r15, ... is used for exception return.
Signed-off-by: Sergey Sorokin
---
target-arm/translate.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 68671b7..3e64ba9 100644
--- a
The rules for setting the CPSR on a 32-bit exception return are
subtly different from those for setting the CPSR via an instruction
like MSR or CPS. (In particular, in Hyp mode changing the mode bits
is not valid via MSR or CPS.) Split the exception-return case into
its own helper for setting CPSR
On 15.02.2016 20:22, Peter Maydell wrote:
> The rules for setting the CPSR on a 32-bit exception return are
> subtly different from those for setting the CPSR via an instruction
> like MSR or CPS. (In particular, in Hyp mode changing the mode bits
> is not valid via MSR or CPS
The rules for setting the CPSR on a 32-bit exception return are
subtly different from those for setting the CPSR via an instruction
like MSR or CPS. (In particular, in Hyp mode changing the mode bits
is not valid via MSR or CPS.) Split the exception-return case into
its own helper for setting CPSR
On 14.01.2016 21:34, Peter Maydell wrote:
> The architecture requires that for an exception return to AArch32 the
> low bits of ELR_ELx are ignored when the PC is set from them:
> * if returning to Thumb mode, ignore ELR_ELx[0]
> * if returning to ARM mode, ignore ELR_ELx[1:0]
>
1 - 100 of 116 matches
Mail list logo
