[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 4/4] exec: refactor cpu_restore_state
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH 4/4] exec: refactor cpu_restore_state |
Date: |
Tue, 4 Dec 2012 21:25:21 +0000 |
On 4 December 2012 21:20, Blue Swirl <address@hidden> wrote:
> diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
> index 6e3ab90..1fcc975 100644
> --- a/target-arm/op_helper.c
> +++ b/target-arm/op_helper.c
> @@ -74,19 +74,13 @@ uint32_t HELPER(neon_tbl)(CPUARMState *env, uint32_t
> ireg, uint32_t def,
> void tlb_fill(CPUARMState *env, target_ulong addr, int is_write, int mmu_idx,
> uintptr_t retaddr)
> {
> - TranslationBlock *tb;
> int ret;
>
> ret = cpu_arm_handle_mmu_fault(env, addr, is_write, mmu_idx);
> if (unlikely(ret)) {
> if (retaddr) {
> /* now we have a real cpu fault */
> - tb = tb_find_pc(retaddr);
> - if (tb) {
> - /* the PC is inside the translated code. It means that we
> have
> - a virtual CPU fault */
> - cpu_restore_state(tb, env, retaddr);
> - }
> + cpu_restore_state(env, retaddr);
> }
> raise_exception(env, env->exception_index);
> }
So this is just a refactoring, but it prompts me to ask -- how does
this work if the PC that caused us to take this TLB fill is legitimately
zero? We seem to be overloading retaddr==0 as a "not a real cpu fault"
indicator...
-- PMM
- [Qemu-devel] [PATCH 0/4] exec.c refactoring, Blue Swirl, 2012/12/04
- [Qemu-devel] [PATCH 2/4] exec: extract TB watchpoint check, Blue Swirl, 2012/12/04
- [Qemu-devel] [PATCH 3/4] exec: move TB handling to translate-all.c, Blue Swirl, 2012/12/04
- [Qemu-devel] [PATCH 1/4] exec: fix coding style, Blue Swirl, 2012/12/04
- [Qemu-devel] [PATCH 4/4] exec: refactor cpu_restore_state, Blue Swirl, 2012/12/04
- Re: [Qemu-devel] [PATCH 4/4] exec: refactor cpu_restore_state,
Peter Maydell <=
- Re: [Qemu-devel] [PATCH 4/4] exec: refactor cpu_restore_state, Andreas Färber, 2012/12/05
- Re: [Qemu-devel] [PATCH 4/4] exec: refactor cpu_restore_state, Aurelien Jarno, 2012/12/06