Re: [Qemu-ppc] [RFC for-2.13 11/12] target/ppc: Remove unnecessary POWERPC_MMU_V3 flag from mmu_model

[David Gibson]

On Wed, Mar 28, 2018 at 12:19:37PM +0200, Cédric Le Goater wrote:
> On 03/28/2018 10:47 AM, David Gibson wrote:
> > On Wed, Mar 28, 2018 at 09:49:25AM +0200, Cédric Le Goater wrote:
> >> On 03/28/2018 09:43 AM, Cédric Le Goater wrote:
> >>> On 03/27/2018 06:37 AM, David Gibson wrote:
> >>>> The only place we test this flag is in conjunction with
> >>>> ppc64_use_proc_tbl().  That checks for the LPCR_UPRT bit, which we 
> >>>> already
> >>>> ensure can't be set except on a machine with a v3 MMU (i.e. POWER9).
> >>>
> >>> hmm, ok, but what will I use for the PowerNV hash MMU support then ? 
> >>
> >> That will be POWERPC_MMU_3_00.
> > 
> > You could check for that explicitly, or you could just check for
> > presence of non-NULL hash64_opts.  The idea is that will always be the
> > case for cpus capable of using the hash MMU.
> 
> ok. I will rebase when your patchset is merged.
>  
> > I'm also considering adding a similar radix_opts with radix specific
> > details.  
> 
> yes. It looks a bit unbalanced now.

Right.  In theory it would be nice to split out hash32 / BookE /
whatever options into their own substructures as well, but I doubt
anyone will ever care enough to actually do it.

> > POWER9 would have both, since it can support either mode.
> > 
> >> I didn't realize mmu_model was so 
> >> crowded ..
> > 
> > It's not so that it's short of space.  It's more that the mix of enum
> > like pieces and bitflag like pieces like bits makes it confusing to
> > know whether it should be tested with simple equality or with &.  And
> > if testing with equality which bits should be masked for a sensible
> > comparison.
> > 
> > Additionally, I'd like to get options that are strictly related to the
> > hash mmu out of the general structures.
> 
> which are ? vrma_slb, rmls ?

Ah.. so.. for now I'm just thinking about MMU options / capabilities
rather than MMU state.  That is, things which are set at
initialization but then don't change.  rmls and vrma_slb don't fit in
that category.  slb_nr does, though - I had a shot at moving it to
hash64_opts, but hit some complications, so I might come back to it
later.

-- 
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