From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: David Laight <David.Laight@aculab.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
phileas-fogg@mail.ru, geoff@infradead.org
Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
Date: Wed, 13 Feb 2013 23:37:51 +0530 [thread overview]
Message-ID: <87halgjde0.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <87mwv8jnmj.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> David Laight <David.Laight@aculab.com> writes:
>
>>> +#define CONTEXT_BITS 19
>>> +#define USER_ESID_BITS 18
>>> +#define USER_ESID_BITS_1T 6
>>> +
>>> +/*
>>> + * 256MB segment
>>> + * The proto-VSID space has 2^(CONTEX_BITS + USER_ESID_BITS) - 1 segments
>>> + * available for user + kernel mapping. The top 4 contexts are used for
>>> + * kernel mapping. Each segment contains 2^28 bytes. Each
>>> + * context maps 2^46 bytes (64TB) so we can support 2^19-1 contexts
>>> + * (19 == 37 + 28 - 46).
>>> + */
>>
>> I can't help feeling this would be easier to understand if a full
>> 64? 80? bit address was shown with the various bit ranges identified.
>>
>> Given the comment, I'd have expected CONTEXT_BITS to be calculated
>> from three other named constants - rather than being set to 19.
>>
>
> May be the comments were misleading. We build proto vsid using a
> combination of context and ea bits.
>
> Current code does the below:
>
> for kernel:
> proto_vsid = ea >> SID_SHIFT;
> proto_vsid |= (1UL << (CONTEXT_BITS + USER_ESID_BITS));
> for user:
> proto_vsid = ea >> SID_SHIFT
> proto_vsid |= context << USER_ESID_BITS
>
> context range is 0 - (2^19 -1)
>
> With this patch we _don't_ give kernel half the proto vsid range.
> Instead, we reduce the proto vsid range and then the kernel is given
> top 4 context. ie, kernel proto vsid is now
>
> for kenel:
> proto_vsid = ea >> SID_SHIFT;
> context = (MAX_CONTEXT - 4) + ((effective address >> 60) - 0xc);
> proto_vsid |= context << USER_ESID_BITS
>
Hmm that may be an issue, considering ESID for kernel is 36 bits.
We have overlapping bits between shifted value of context and kernel
ESID.
-aneesh
next prev parent reply other threads:[~2013-02-13 18:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 18:31 [PATCH 1/2] powerpc: Make VSID_BITS* dependency explicit Aneesh Kumar K.V
2013-02-12 18:31 ` [PATCH 2/2] powerpc: Make context bits depend on virtual addr size Aneesh Kumar K.V
2013-02-12 20:33 ` Benjamin Herrenschmidt
2013-02-13 3:24 ` Aneesh Kumar K.V
2013-02-13 3:46 ` Benjamin Herrenschmidt
2013-02-13 11:40 ` Aneesh Kumar K.V
2013-02-13 13:27 ` David Laight
2013-02-13 14:26 ` Aneesh Kumar K.V
2013-02-13 18:07 ` Aneesh Kumar K.V [this message]
2013-02-13 18:13 ` Re[2]: " Phileas Fogg
2013-02-13 20:09 ` Geoff Levand
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=87halgjde0.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=David.Laight@aculab.com \
--cc=benh@kernel.crashing.org \
--cc=geoff@infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.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 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.