linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: phileas-fogg@mail.ru, linuxppc-dev@lists.ozlabs.org, geoff@infradead.org
Subject: Re: [PATCH 2/4] powerpc: Update kernel VSID range
Date: Fri, 15 Feb 2013 15:42:28 +1100	[thread overview]
Message-ID: <20130215044228.GE25015@drongo> (raw)
In-Reply-To: <1360830983-1812-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>

On Thu, Feb 14, 2013 at 02:06:21PM +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) - 6)
> for kernel space, we use the top 4 context ids to map address as below
> 0x7fffb -  [ 0xc000000000000000 - 0xcfffffffffffffff ]

Actually, each context only gives us 64TB, so the range here would be
0xc000000000000000 - 0xc0003fffffffffff.  Similarly for the others.

> 0x7fffc -  [ 0xd000000000000000 - 0xdfffffffffffffff ]
> 0x7fffd -  [ 0xe000000000000000 - 0xefffffffffffffff ]
> 0x7fffe -  [ 0xf000000000000000 - 0xffffffffffffffff ]

We could increase all these context numbers by 1.  We have to avoid
the last ESID of the last context because of the modulo operation in
the vsid scramble, but the vmemmap (which is what uses region 0xf)
will never be close to 64TB in size (it's 56 bytes per page of system
memory).

[snip]
> +static inline unsigned long get_kernel_vsid(unsigned long ea, int ssize)
> +{
> +	unsigned long context;
> +	/*
> +	 * kernel take the top 4 context from the available range
> +	 */

You should check the ea here, and if it is out of range (below 0xc...,
or with any of the 0x0fffc00000000000 bits set), return 0, which is
the reserved vsid.

> +	context = (MAX_CONTEXT - 4) +  ((ea >> 60) - 0xc);
> +	return get_vsid(context, ea, ssize);
> +}
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* _ASM_POWERPC_MMU_HASH64_H_ */
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index 4665e82..d8f6804 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -1268,17 +1268,24 @@ do_ste_alloc:
>  _GLOBAL(do_stab_bolted)
>  	stw	r9,PACA_EXSLB+EX_CCR(r13)	/* save CR in exc. frame */
>  	std	r11,PACA_EXSLB+EX_SRR0(r13)	/* save SRR0 in exc. frame */
> +	mfspr	r11,SPRN_DAR			/* ea */
> +
> +	/*
> +	 * Calculate VSID:
> +	 * This is the kernel vsid, we take the top for context from
> +	 * the range. context = (MAX_CONTEXT - 4) + ((ea >> 60) - 0xc)
> +	 */
> +	srdi	r9,r11,60
> +	subi	r9,r9,(0xc + 4 + 1)
> +	lis	r10,8
> +	add	r9,r9,r10		/* context */

At this point we know the top 4 bits of EA are 0xc, so the context is
a constant which we can load with 2 instructions.  We do also need to
check the middle bits (0x0fff_c000_0000_0000) and use a VSID of 0 if
any of them are set.

> diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
> index 1a16ca2..487f998 100644
> --- a/arch/powerpc/mm/slb_low.S
> +++ b/arch/powerpc/mm/slb_low.S
> @@ -56,12 +56,19 @@ _GLOBAL(slb_allocate_realmode)
>  	 */
>  _GLOBAL(slb_miss_kernel_load_linear)
>  	li	r11,0
> -	li	r9,0x1
> +	/*
> +	 * context = (MAX_CONTEXT - 4) + ((ea >> 60) - 0xc)
> +	 */
> +	srdi	r9,r3,60
> +	subi	r9,r9,(0xc + 4 + 1)
> +	lis	r10, 8
> +	add	r9,r9,r10
> +	srdi	r10,r3,28 /* FIXME!! doing it twice */

Also need to check the middle bits here and for the 1T case.

Paul.

  parent reply	other threads:[~2013-02-15  4:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <a>
2013-02-14  8:36 ` [PATCH 1/4] powerpc: Make VSID_BITS* dependency explicit Aneesh Kumar K.V
2013-02-14  8:36   ` [PATCH 2/4] powerpc: Update kernel VSID range Aneesh Kumar K.V
2013-02-14 17:21     ` Aneesh Kumar K.V
2013-02-15  4:42     ` Paul Mackerras [this message]
2013-02-14  8:36   ` [PATCH 3/4] powerpc: Don't update r10 early in the call Aneesh Kumar K.V
2013-02-14  8:36   ` [PATCH 4/4] powerpc: Add vm debug code to catch errors Aneesh Kumar K.V
2013-02-15  4:46     ` 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=20130215044228.GE25015@drongo \
    --to=paulus@samba.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=geoff@infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=phileas-fogg@mail.ru \
    /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).