From: "Phileas Fogg" <phileas-fogg@mail•ru>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux•vnet.ibm.com>
Cc: "Geoff Levand" <geoff@infradead•org>, linuxppc-dev@lists•ozlabs.org
Subject: Re[5]: PS3 platform is broken on Linux 3.7.0
Date: Mon, 11 Feb 2013 20:57:43 +0400 [thread overview]
Message-ID: <1360601863.295233799@f126.mail.ru> (raw)
In-Reply-To: <87zjzb4051.fsf@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2859 bytes --]
>"Aneesh Kumar K.V" < aneesh.kumar@linux•vnet.ibm.com > writes:
>
>> Phileas Fogg < phileas-fogg@mail•ru > writes:
>>
>>> And another note.
>>> I took a look at the MMU chapter in the Cell Architecture handbook and indeed the first 15 bits in VA are treated as 0 by the hardware.
>>>
>>> Quote:
>>>
>>> 1. High-order bits above 65 bits in the 80-bit virtual address (VA[0:14]) are not implemented. The hardware always
>>> treats these bits as `0'. Software must not set these bits to any other value than `0' or the results are undefined in
>>> the PPE.
>>>
>>>
>>
>> True, we missed the below part of ISA doc:
>>
>> ISA doc says
>>
>> "On implementations that support a virtual address size
>> of only n bits, n < 78, bits 0:77-n of the AVA field must be
>> zeros. "
>>
>> The Cell document I found at
>>
>> https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/7A77CCDF14FE70D5852575CA0074E8ED/$file/CellBE_Handbook_v1.12_3Apr09_pub.pdf
>>
>> gives
>>
>> Virtual Address (VA) Size -> 65 bits
>>
>> So as per ISA, bits 0:12 should be zero, which should make 0:14 of PTE
>> fields zero for Cell.
>>
>> I will try to do a patch.
>>
>
>Can you try this patch ?
>
>diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
>index 2fdb47a..f01fd9a 100644
>--- a/arch/powerpc/include/asm/mmu-hash64.h
>+++ b/arch/powerpc/include/asm/mmu-hash64.h
>@@ -381,21 +381,37 @@ extern void slb_set_size(u16 size);
> * hash collisions.
> */
>
>+/* This should go in Kconfig */
>+/*
>+ * Be careful with this value. This determines the VSID_MODULUS_* and that
>+ * need to be co-prime with VSID_MULTIPLIER*
>+ */
>+#if 1
>+#define MAX_VIRTUAL_ADDR_BITS 65
>+#else
>+#define MAX_VIRTUAL_ADDR_BITS 66
>+#endif
>+/*
>+ * One bit is taken by the kernel, only the rest of space is available for the
>+ * user space.
>+ */
>+#define CONTEXT_BITS (MAX_VIRTUAL_ADDR_BITS - \
>+ (USER_ESID_BITS + SID_SHIFT + 1))
>+#define USER_ESID_BITS 18
>+#define USER_ESID_BITS_1T 6
>+
> /*
> * This should be computed such that protovosid * vsid_mulitplier
> * doesn't overflow 64 bits. It should also be co-prime to vsid_modulus
> */
> #define VSID_MULTIPLIER_256M ASM_CONST(12538073) /* 24-bit prime */
>-#define VSID_BITS_256M 38
>+#define VSID_BITS_256M (CONTEXT_BITS + USER_ESID_BITS + 1)
> #define VSID_MODULUS_256M ((1UL<<VSID_BITS_256M)-1)
>
> #define VSID_MULTIPLIER_1T ASM_CONST(12538073) /* 24-bit prime */
>-#define VSID_BITS_1T 26
>+#define VSID_BITS_1T (CONTEXT_BITS + USER_ESID_BITS_1T + 1)
> #define VSID_MODULUS_1T ((1UL<<VSID_BITS_1T)-1)
>
>-#define CONTEXT_BITS 19
>-#define USER_ESID_BITS 18
>-#define USER_ESID_BITS_1T 6
>
> #define USER_VSID_RANGE (1UL << (USER_ESID_BITS + SID_SHIFT))
>
>
Testing it with Linux 3.8.0-rc7, it looks good so far under heavy hard disk usage.
[-- Attachment #2: Type: text/html, Size: 4105 bytes --]
next prev parent reply other threads:[~2013-02-11 16:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-14 12:35 PS3 platform is broken on Linux 3.7.0 Phileas Fogg
2012-12-19 21:53 ` Benjamin Herrenschmidt
2013-01-12 2:12 ` Geoff Levand
2013-01-14 23:37 ` Geoff Levand
2013-02-10 8:59 ` Re[2]: " Phileas Fogg
2013-02-10 9:16 ` Re[3]: " Phileas Fogg
2013-02-10 16:11 ` Aneesh Kumar K.V
2013-02-11 10:26 ` Aneesh Kumar K.V
2013-02-11 16:57 ` Phileas Fogg [this message]
2013-02-12 1:11 ` Geoff Levand
2013-02-11 20:56 ` Re[2]: " Geoff Levand
2013-02-10 11:45 ` Phileas Fogg
2013-02-10 12:17 ` Re[3]: " Phileas Fogg
2013-02-10 15:46 ` Aneesh Kumar K.V
2013-02-10 17:51 ` Re[5]: " Phileas Fogg
2013-02-11 3:39 ` Michael Ellerman
2013-02-13 7:32 ` Geoff Levand
2013-02-13 22:37 ` Michael Ellerman
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=1360601863.295233799@f126.mail.ru \
--to=phileas-fogg@mail$(echo .)ru \
--cc=aneesh.kumar@linux$(echo .)vnet.ibm.com \
--cc=geoff@infradead$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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