Patchwork [-V3,05/11] arch/powerpc: remove masking top 16 bit of va in tlb invalidate

login
register
mail settings
Submitter Aneesh Kumar K.V
Date July 9, 2012, 1:13 p.m.
Message ID <1341839621-28332-6-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
Download mbox | patch
Permalink /patch/169822/
State Changes Requested
Delegated to: Benjamin Herrenschmidt
Headers show

Comments

Aneesh Kumar K.V - July 9, 2012, 1:13 p.m.
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>

ISA doc doesn't talk about this. As per ISA doc for a 4K page

     tlbie RB RS

" The Abbreviated Virtual Address (AVA) field in register RB must
  contain bits 14:65 of the virtual address translated by the TLB
  entry to be invalidated."

That indicate we should not mask the top 16 bits. So remove the same.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
 arch/powerpc/mm/hash_native_64.c |    6 ------
 1 file changed, 6 deletions(-)
Paul Mackerras - July 22, 2012, 11:56 p.m.
On Mon, Jul 09, 2012 at 06:43:35PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
> 
> ISA doc doesn't talk about this. As per ISA doc for a 4K page
> 
>      tlbie RB RS
> 
> " The Abbreviated Virtual Address (AVA) field in register RB must
>   contain bits 14:65 of the virtual address translated by the TLB
>   entry to be invalidated."
> 
> That indicate we should not mask the top 16 bits. So remove the same.

Older versions of the architecture (2.02 and earler) require the
masking, so we can't just unconditionally remove it, since that would
potentially break POWER5 and PPC970.  People are definitely still
running Linux bare-metal on PPC970s (though arguably not on POWER5).

Paul.
Benjamin Herrenschmidt - July 23, 2012, 1:22 a.m.
On Mon, 2012-07-23 at 09:56 +1000, Paul Mackerras wrote:
> > That indicate we should not mask the top 16 bits. So remove the
> same.
> 
> Older versions of the architecture (2.02 and earler) require the
> masking, so we can't just unconditionally remove it, since that would
> potentially break POWER5 and PPC970.  People are definitely still
> running Linux bare-metal on PPC970s (though arguably not on POWER5). 

Are you sure ? I couldn't convince myself ... the old architectures say
that it only uses some of the bits but it doesn't mark the other ones as
"reserved" (as in must be 0).

(At least 1.x, I haven't looked at 2.x with x < 03)

Cheers,
Ben.
Paul Mackerras - July 23, 2012, 3:49 a.m.
On Mon, Jul 23, 2012 at 11:22:08AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-23 at 09:56 +1000, Paul Mackerras wrote:
> > > That indicate we should not mask the top 16 bits. So remove the
> > same.
> > 
> > Older versions of the architecture (2.02 and earler) require the
> > masking, so we can't just unconditionally remove it, since that would
> > potentially break POWER5 and PPC970.  People are definitely still
> > running Linux bare-metal on PPC970s (though arguably not on POWER5). 
> 
> Are you sure ? I couldn't convince myself ... the old architectures say
> that it only uses some of the bits but it doesn't mark the other ones as
> "reserved" (as in must be 0).
> 
> (At least 1.x, I haven't looked at 2.x with x < 03)

2.01 and 2.02 say bits 0..15 must be zero.

Paul.
Aneesh Kumar K.V - July 23, 2012, 6:44 a.m.
Paul Mackerras <paulus@samba.org> writes:

> On Mon, Jul 23, 2012 at 11:22:08AM +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2012-07-23 at 09:56 +1000, Paul Mackerras wrote:
>> > > That indicate we should not mask the top 16 bits. So remove the
>> > same.
>> > 
>> > Older versions of the architecture (2.02 and earler) require the
>> > masking, so we can't just unconditionally remove it, since that would
>> > potentially break POWER5 and PPC970.  People are definitely still
>> > running Linux bare-metal on PPC970s (though arguably not on POWER5). 
>> 
>> Are you sure ? I couldn't convince myself ... the old architectures say
>> that it only uses some of the bits but it doesn't mark the other ones as
>> "reserved" (as in must be 0).
>> 
>> (At least 1.x, I haven't looked at 2.x with x < 03)
>
> 2.01 and 2.02 say bits 0..15 must be zero.

is this 0..15 of va or 0..15 of AVA ?

if it is 0.. 15 then that clear bit is wrong right ? We are doing that
on a 64 bit va. So with that we already have ignored 0..14. 

-aneesh
Benjamin Herrenschmidt - July 23, 2012, 6:48 a.m.
On Mon, 2012-07-23 at 12:14 +0530, Aneesh Kumar K.V wrote:
> 
> if it is 0.. 15 then that clear bit is wrong right ? We are doing that
> on a 64 bit va. So with that we already have ignored 0..14. 

It's bit 0..15 of RB passed to tlbie

Cheers,
Ben.

Patch

diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index b019f2d..9bf8187 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -54,9 +54,6 @@  static inline void __tlbie(unsigned long vpn, int psize, int ssize)
 	BUG_ON((77 - 65) > VPN_SHIFT);
 	va = vpn << VPN_SHIFT;
 
-	/* clear top 16 bits, non SLS segment */
-	va &= ~(0xffffULL << 48);
-
 	switch (psize) {
 	case MMU_PAGE_4K:
 		va |= ssize << 8;
@@ -86,9 +83,6 @@  static inline void __tlbiel(unsigned long vpn, int psize, int ssize)
 	BUG_ON((77 - 65) > VPN_SHIFT);
 	va = vpn << VPN_SHIFT;
 
-	/* clear top 16 bits, non SLS segment */
-	va &= ~(0xffffULL << 48);
-
 	switch (psize) {
 	case MMU_PAGE_4K:
 		va |= ssize << 8;