qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/9] sparc64: use helper_wrpil to check pending


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 3/9] sparc64: use helper_wrpil to check pending irq on write
Date: Wed, 6 Jan 2010 15:41:58 +0000

On Tue, Jan 5, 2010 at 11:19 PM, Igor V. Kovalenko
<address@hidden> wrote:
> From: Igor V. Kovalenko <address@hidden>
>
> Signed-off-by: Igor V. Kovalenko <address@hidden>
> ---
>  target-sparc/helper.h    |    1 +
>  target-sparc/op_helper.c |   14 ++++++++++++++
>  target-sparc/translate.c |    5 +----
>  3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/target-sparc/helper.h b/target-sparc/helper.h
> index 4002b9e..6f103e7 100644
> --- a/target-sparc/helper.h
> +++ b/target-sparc/helper.h
> @@ -5,6 +5,7 @@ DEF_HELPER_0(rett, void)
>  DEF_HELPER_1(wrpsr, void, tl)
>  DEF_HELPER_0(rdpsr, tl)
>  #else
> +DEF_HELPER_1(wrpil, void, tl)
>  DEF_HELPER_1(wrpstate, void, tl)
>  DEF_HELPER_0(done, void)
>  DEF_HELPER_0(retry, void)
> diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
> index 26092e5..a7da0e4 100644
> --- a/target-sparc/op_helper.c
> +++ b/target-sparc/op_helper.c
> @@ -3303,6 +3303,20 @@ void helper_wrpstate(target_ulong new_state)
>     change_pstate(new_state & 0xf3f);
>  }
>
> +void helper_wrpil(target_ulong new_pil)
> +{
> +    DPRINTF_PSTATE("helper_wrpil old=%X new=%X\n",
> +                   env->psrpil, (uint32_t)new_pil);
> +
> +    env->psrpil = new_pil;
> +
> +#if !defined(CONFIG_USER_ONLY)
> +    if (env->pstate & PS_IE) {
> +        cpu_check_irqs(env);
> +    }
> +#endif
> +}

It's not possible to write to PIL in user mode, so the whole code
inside the function should be surrounded by #if
!defined(CONFIG_USER_ONLY)/#endif. Please use lowercase hex.

I'm wondering about using target_ulong instead of uint32_t (type of
env->psrpil). TL makes the generated code shorter, uint32_t would
decrease TCG register pressure on 32 bit hosts. This is not
performance critical, so either way should be OK.




reply via email to

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