Re: [RFC PATCH v3 3/3] target/ppc: Fix gen_priv_exception error value in mfspr/mtspr

[Laurent Vivier]

Le 13/01/2022 à 18:04, matheus.ferst@eldorado.org.br a écrit :
> From: Matheus Ferst <matheus.ferst@eldorado.org.br>
>
> The code in linux-user/ppc/cpu_loop.c expects POWERPC_EXCP_PRIV
> exception with error POWERPC_EXCP_PRIV_OPC or POWERPC_EXCP_PRIV_REG,
> while POWERPC_EXCP_INVAL_SPR is expected in POWERPC_EXCP_INVAL
> exceptions. This mismatch caused an EXCP_DUMP with the message "Unknown
> privilege violation (03)", as seen in [1].
>
> Fixes: 9b2fadda3e01 ("ppc: Rework generation of priv and inval interrupts")
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/588
>
> [1] https://gitlab.com/qemu-project/qemu/-/issues/588
>
> Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br>
> ---
> Is there any case where throwing a PRIV/INVAL exception with a
> INVAL/PRIV error makes sense? It seems wrong, but maybe I'm missing
> something... especially with the HV_EMU to program check conversion.
>
> Also, if this patch is correct, it seems that all invalid SPR access
> would be nop or privilege exceptions. In this case, is
> POWERPC_EXCP_INVAL_SPR still needed?
> ---
>   target/ppc/translate.c | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index 40232201bb..abbc3a5bb9 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -4827,11 +4827,11 @@ static inline void gen_op_mfspr(DisasContext *ctx)
>            */
>           if (sprn & 0x10) {
>               if (ctx->pr) {
> -                gen_priv_exception(ctx, POWERPC_EXCP_INVAL_SPR);
> +                gen_priv_exception(ctx, POWERPC_EXCP_PRIV_REG);
>               }
>           } else {
>               if (ctx->pr || sprn == 0 || sprn == 4 || sprn == 5 || sprn == 6) {
> -                gen_hvpriv_exception(ctx, POWERPC_EXCP_INVAL_SPR);
> +                gen_hvpriv_exception(ctx, POWERPC_EXCP_PRIV_REG);
>               }
>           }
>       }
> @@ -5014,11 +5014,11 @@ static void gen_mtspr(DisasContext *ctx)
>            */
>           if (sprn & 0x10) {
>               if (ctx->pr) {
> -                gen_priv_exception(ctx, POWERPC_EXCP_INVAL_SPR);
> +                gen_priv_exception(ctx, POWERPC_EXCP_PRIV_REG);
>               }
>           } else {
>               if (ctx->pr || sprn == 0) {
> -                gen_hvpriv_exception(ctx, POWERPC_EXCP_INVAL_SPR);
> +                gen_hvpriv_exception(ctx, POWERPC_EXCP_PRIV_REG);
>               }
>           }
>       }

It seems logic to emit a POWERPC_EXCP_PRIV_XXX exception with  
gen_priv_exception() (POWERPC_EXCP_PRIV).

Moreover in line above we have a  gen_priv_exception(ctx, POWERPC_EXCP_PRIV_REG) if the register 
cannot be read (SPR_NOACCESS).

But in helper_load_dcr() we have POWERPC_EXCP_PRIV_REG with POWERPC_EXCP_INVAL (whereas in the 
helper_store_dcr() function we have POWERPC_EXCP_INVAL with POWERPC_EXCP_INVAL_INVAL).
It looks like another bug.

and in gen_slbfee() we have also a POWERPC_EXCP_PRIV_REG with gen_inval_exception() 
(POWERPC_EXCP_INVAL).

What is interesting is gen_inval_exception() uses POWERPC_EXCP_HV_EMU that could make thinking we 
could try to emulate the operation (for KVM PR, for instance).

Thanks,
Laurent