Re: [Qemu-devel] [PATCH 06/10] ppc: Rework generation of priv and inval interrupts

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2016-06-15 at 11:19 +1000, David Gibson wrote:
> 
> >  static void spr_noaccess(DisasContext *ctx, int gprn, int sprn)
> > @@ -4348,9 +4371,15 @@ static inline void gen_op_mfspr(DisasContext *ctx)
> >                               TARGET_FMT_lx "\n", sprn, sprn, ctx->nip - 4);
> >                  }
> >              }
> > -            gen_inval_exception(ctx, POWERPC_EXCP_PRIV_REG);
> > +            gen_priv_exception(ctx, POWERPC_EXCP_PRIV_REG);
> >          }
> >      } else {
> > +        /* ISA 2.07 defines these as no-ops */
> > +        if ((ctx->insns_flags2 & PPC2_ISA207S) &&
> > +            (sprn >= 808 && sprn <= 811)) {
> > +            /* This is a nop */
> > +            return;
> > +        }
> >          /* Not defined */
> >          fprintf(stderr, "Trying to read invalid spr %d (0x%03x) at "
> >                  TARGET_FMT_lx "\n", sprn, sprn, ctx->nip - 4);
> > @@ -4358,9 +4387,18 @@ static inline void gen_op_mfspr(DisasContext *ctx)
> >              qemu_log("Trying to read invalid spr %d (0x%03x) at "
> >                       TARGET_FMT_lx "\n", sprn, sprn, ctx->nip - 4);
> >          }
> > -        /* Only generate an exception in user space, otherwise this is a nop */
> > -        if (ctx->pr) {
> > -            gen_inval_exception(ctx, POWERPC_EXCP_INVAL_SPR);
> > +
> > +        /* The behaviour depends on MSR:PR and SPR# bit 0x10,
> > +         * it can generate a priv, a hv emu or a no-op
> > +         */
> > +        if (sprn & 0x10) {
> > +            if (ctx->pr) {
> > +                gen_priv_exception(ctx, POWERPC_EXCP_INVAL_SPR);
> > +            }
> > +        } else {
> > +            if (ctx->pr || sprn == 0 || sprn == 4 || sprn == 5 || sprn == 6) {
> > +                gen_hvpriv_exception(ctx, POWERPC_EXCP_INVAL_SPR);
> 
> Just double checking this logic.  So in this case we get an exception
> to the hypervisor if executed in guest user mode, but a no-op if
> 
> executed in guest supervisor mode.  That seems.. odd.

From the architecture:

* if spr 0 =0:
  - if MSR PR =1: Hypervisor Emulation Assistance
    interrupt
  - if MSR PR =0: Hypervisor Emulation Assistance
    interrupt for SPRs 0, 4, 5, and 6 and no opera-
    tion (i.e. the instruction is treated as a no-op)
    for all other SPRs
„
* if spr 0 =1:
  - if MSR PR =1: Privileged Instruction type Pro-
    gram interrupt
  - if MSR PR =0: no operation (i.e. the instruction
    is treated as a no-op)

IE. SPRs with 0x10 are supervisor priv, so PR access will trap to
the OS, whether they are implemented or not.

Otherwise, you get the "system illegal isntruction" handler which
is turned into an HVPRIV on all recent processors (the exception code
will turn that back into a 0x700 if the processor doesn't support
HVPRIV).

It was done this way so that an OS (guest) can context switch a bunch
of supervisor SPRs without having to test if they individually exist
on a given processor.

Cheers,
Ben.

>