All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: qemu-ppc@nongnu.org, groug@kaod.org, agraf@suse.de,
	qemu-devel@nongnu.org, benh@kernel.crashing.org,
	bharata@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [RFC for-2.13 11/12] target/ppc: Remove unnecessary POWERPC_MMU_V3 flag from mmu_model
Date: Thu, 29 Mar 2018 16:02:06 +1100	[thread overview]
Message-ID: <20180329050206.GM3510@umbus.fritz.box> (raw)
In-Reply-To: <1e220d03-11cf-2c8d-d3ba-b816741fa4e3@kaod.org>

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-03-29  5:02 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27  4:37 [Qemu-devel] [RFC for-2.13 00/12] target/ppc: Assorted cpu cleanups (esp. hash64 MMU) David Gibson
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 01/12] target/ppc: Standardize instance_init and realize function names David Gibson
2018-03-27  7:12   ` Greg Kurz
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 02/12] target/ppc: Simplify cpu valid check in ppc_cpu_realize David Gibson
2018-03-27  6:36   ` [Qemu-devel] [Qemu-ppc] " Thomas Huth
2018-03-27  7:13   ` [Qemu-devel] " Greg Kurz
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 03/12] target/ppc: Pass cpu instead of env to ppc_create_page_sizes_prop() David Gibson
2018-03-27  7:15   ` Greg Kurz
2018-03-27  8:41   ` Cédric Le Goater
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 04/12] target/ppc: Avoid taking "env" parameter to mmu-hash64 functions David Gibson
2018-03-27  8:17   ` Greg Kurz
2018-03-27  8:45   ` Cédric Le Goater
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 05/12] target/ppc: Remove fallback 64k pagesize information David Gibson
2018-03-27  8:54   ` Cédric Le Goater
2018-03-27 13:54   ` Greg Kurz
2018-03-28  0:32     ` David Gibson
2018-03-28  8:01       ` Greg Kurz
2018-03-28  8:54         ` David Gibson
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 06/12] target/ppc: Move page size setup to helper function David Gibson
2018-03-27  8:56   ` Cédric Le Goater
2018-03-27 13:58   ` Greg Kurz
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 07/12] target/ppc: Split page size information into a separate allocation David Gibson
2018-03-28  7:28   ` Cédric Le Goater
2018-03-29  4:46     ` David Gibson
2018-03-28  8:15   ` Greg Kurz
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 08/12] target/ppc: Make hash64_opts field mandatory for 64-bit hash MMUs David Gibson
2018-03-28  7:31   ` Cédric Le Goater
2018-03-28  8:33   ` Greg Kurz
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 09/12] target/ppc: Move 1T segment and AMR options to PPCHash64Options David Gibson
2018-03-28  7:40   ` Cédric Le Goater
2018-03-29  4:57     ` David Gibson
2018-03-28  8:48   ` Greg Kurz
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 10/12] target/ppc: Fold ci_large_pages flag into PPCHash64Options David Gibson
2018-03-28  7:41   ` Cédric Le Goater
2018-03-28  8:50   ` Greg Kurz
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 11/12] target/ppc: Remove unnecessary POWERPC_MMU_V3 flag from mmu_model David Gibson
2018-03-28  7:43   ` Cédric Le Goater
2018-03-28  7:49     ` Cédric Le Goater
2018-03-28  8:47       ` David Gibson
2018-03-28 10:19         ` Cédric Le Goater
2018-03-29  5:02           ` David Gibson [this message]
2018-03-28  9:10   ` Greg Kurz
2018-03-27  4:37 ` [Qemu-devel] [RFC for-2.13 12/12] target/ppc: Get rid of POWERPC_MMU_VER() macros David Gibson
2018-03-28  7:50   ` Cédric Le Goater
2018-03-28  9:26   ` Greg Kurz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180329050206.GM3510@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=agraf@suse.de \
    --cc=benh@kernel.crashing.org \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=clg@kaod.org \
    --cc=groug@kaod.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.