qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]