Re: [PATCH v2 26/28] target/ppc: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX

[David Gibson]

On Sun, Dec 29, 2019 at 08:18:35AM +1100, Richard Henderson wrote:
> On 12/21/19 6:51 AM, Alex Bennée wrote:
> >> --- a/target/ppc/mem_helper.c
> >> +++ b/target/ppc/mem_helper.c
> >> @@ -177,14 +177,7 @@ static void dcbz_common(CPUPPCState *env, 
> >> target_ulong addr,
> >>      } else {
> >>          /* Slow path */
> >>          for (i = 0; i < dcbz_size; i += 8) {
> >> -            if (epid) {
> >> -#if !defined(CONFIG_USER_ONLY)
> >> -                /* Does not make sense on USER_ONLY config */
> >> -                cpu_stq_eps_ra(env, addr + i, 0, retaddr);
> >> -#endif
> >> -            } else {
> >> -                cpu_stq_data_ra(env, addr + i, 0, retaddr);
> >> -            }
> >> +            cpu_stq_mmuidx_ra(env, addr + i, 0, mmu_idx, retaddr);
> > 
> > I assume the possibility of a user-mode with epid is elided in the
> > translation phase by avoiding gen_dcbzep although I can't quite see
> > where they get called from. Anyway:
> 
> I suspect that dcbzep (vs dcbze) is supposed to be privileged, but I can't see
> that enforced anywhere.  Certainly one can't write to the EPSC register from
> userspace...

So... it's true that dcbzep is privileged (as are all the external PID
instructions, I believe).  I'm not certain if the reasoning you used
to guess that was correct, though.  In this case the suffix is "ep"
for "External PID" not "p" for "Privileged".  There is no "dcbze"
instruction, only "dcbz" which happens not to be privileged.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature