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.

I'm also considering adding a similar radix_opts with radix specific
details.  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.

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