From: Paul Mackerras <paulus@samba.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, David Gibson <dwg@au1.ibm.com>
Subject: Re: [PATCH -V3 2/3] powerpc: Update kernel VSID range
Date: Wed, 13 Mar 2013 14:42:54 +1100 [thread overview]
Message-ID: <20130313034254.GC21125@iris.ozlabs.ibm.com> (raw)
In-Reply-To: <1363090131-14545-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Tue, Mar 12, 2013 at 05:38:50PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> This patch change the kernel VSID range so that we limit VSID_BITS to 37.
> This enables us to support 64TB with 65 bit VA (37+28). Without this patch
> we have boot hangs on platforms that only support 65 bit VA.
>
> With this patch we now have proto vsid generated as below:
>
> We first generate a 37-bit "proto-VSID". Proto-VSIDs are generated
> from mmu context id and effective segment id of the address.
>
> For user processes max context id is limited to ((1ul << 19) - 5)
> for kernel space, we use the top 4 context ids to map address as below
> 0x7fffc - [ 0xc000000000000000 - 0xc0003fffffffffff ]
> 0x7fffd - [ 0xd000000000000000 - 0xd0003fffffffffff ]
> 0x7fffe - [ 0xe000000000000000 - 0xe0003fffffffffff ]
> 0x7ffff - [ 0xf000000000000000 - 0xf0003fffffffffff ]
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Mostly looks OK, and it could go in as is, so
Acked-by: Paul Mackerras <paulus@samba.org>
Some minor comments below...
> + * For user processes max context id is limited to ((1ul << 19) - 6)
should be ((1ul << 19) - 5)
> + * a divide or extra multiply (see below). The scramble function gives
> + * robust scattering in the hash * table (at least based on some initial
^ superfluous *
> + /*
> + * Calculate VSID:
> + * This is the kernel vsid, we take the top for context from
> + * the range. context = (MAX_USER_CONTEXT) + ((ea >> 60) - 0xc) + 1
> + * Here we know that (ea >> 60) == 0xc
> + */
> + lis r9,8
> + subi r9,r9,4 /* context */
Would be nice to do this as:
lis r9, (MAX_USER_CONTEXT+1)@ha
addi r9, r9, (MAX_USER_CONTEXT+1)@l
rather than having the hard-coded 8 and 4.
> int __init_new_context(void)
> {
> int index;
> @@ -56,7 +47,7 @@ again:
> else if (err)
> return err;
>
> - if (index > MAX_CONTEXT) {
> + if (index > (MAX_USER_CONTEXT)) {
Unnecessary extra parentheses.
> _GLOBAL(slb_allocate_realmode)
> - /* r3 = faulting address */
> + /*
> + * check for bad kernel/user address
> + * (ea & ~REGION_MASK) >= PGTABLE_RANGE
> + */
> + rldicr. r9,r3,4,(63 - 46 - 4)
> + bne- 8f
>
> srdi r9,r3,60 /* get region */
> - srdi r10,r3,28 /* get esid */
> + srdi r10,r3,SID_SHIFT /* get esid */
> cmpldi cr7,r9,0xc /* cmp PAGE_OFFSET for later use */
>
> /* r3 = address, r10 = esid, cr7 = <> PAGE_OFFSET */
> @@ -56,12 +61,13 @@ _GLOBAL(slb_allocate_realmode)
> */
> _GLOBAL(slb_miss_kernel_load_linear)
> li r11,0
> - li r9,0x1
> /*
> - * for 1T we shift 12 bits more. slb_finish_load_1T will do
> - * the necessary adjustment
> + * context = (MAX_USER_CONTEXT) + ((ea >> 60) - 0xc) + 1
> */
> - rldimi r10,r9,(CONTEXT_BITS + USER_ESID_BITS),0
> + rldicl r9,r3,4,62
> + addis r9,r9,8
> + subi r9,r9,4
You already have the region ID in r9, so you could do this in two
instructions like this:
addis r9,r9,(MAX_USER_CONTEXT - 0xc + 1)@ha
addi r9,r9,(MAX_USER_CONTEXT - 0xc + 1)@l
> +
> BEGIN_FTR_SECTION
> b slb_finish_load
> END_MMU_FTR_SECTION_IFCLR(MMU_FTR_1T_SEGMENT)
> @@ -91,24 +97,19 @@ _GLOBAL(slb_miss_kernel_load_vmemmap)
> _GLOBAL(slb_miss_kernel_load_io)
> li r11,0
> 6:
> - li r9,0x1
> /*
> - * for 1T we shift 12 bits more. slb_finish_load_1T will do
> - * the necessary adjustment
> + * context = (MAX_USER_CONTEXT) + ((ea >> 60) - 0xc) + 1
> */
> - rldimi r10,r9,(CONTEXT_BITS + USER_ESID_BITS),0
> + rldicl r9,r3,4,62
> + addis r9,r9,8
> + subi r9,r9,4
If you did the context calculation earlier, before the "bne cr7,1f",
you could save 3 more instructions.
Paul.
next prev parent reply other threads:[~2013-03-13 3:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-12 12:08 [PATCH -V3 1/3] powerpc: Make VSID_BITS* dependency explicit Aneesh Kumar K.V
2013-03-12 12:08 ` [PATCH -V3 2/3] powerpc: Update kernel VSID range Aneesh Kumar K.V
2013-03-13 3:42 ` Paul Mackerras [this message]
2013-03-13 9:17 ` Aneesh Kumar K.V
2013-03-13 9:49 ` Benjamin Herrenschmidt
2013-03-13 13:44 ` Aneesh Kumar K.V
2013-03-12 12:08 ` [PATCH -V3 3/3] powerpc: rename USER_ESID_BITS* to ESID_BITS* Aneesh Kumar K.V
2013-03-13 3:43 ` Paul Mackerras
2013-03-13 3:43 ` [PATCH -V3 1/3] powerpc: Make VSID_BITS* dependency explicit Paul Mackerras
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=20130313034254.GC21125@iris.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dwg@au1.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).