]>
Commit | Line | Data |
---|---|---|
10b94b29 GKH |
1 | From 35f2806b481f5b9207f25e1886cba5d1c4d12cc7 Mon Sep 17 00:00:00 2001 |
2 | From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> | |
3 | Date: Fri, 22 Feb 2019 22:55:31 +0530 | |
4 | Subject: powerpc/hugetlb: Don't do runtime allocation of 16G pages in LPAR configuration | |
5 | MIME-Version: 1.0 | |
6 | Content-Type: text/plain; charset=UTF-8 | |
7 | Content-Transfer-Encoding: 8bit | |
8 | ||
9 | From: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> | |
10 | ||
11 | commit 35f2806b481f5b9207f25e1886cba5d1c4d12cc7 upstream. | |
12 | ||
13 | We added runtime allocation of 16G pages in commit 4ae279c2c96a | |
14 | ("powerpc/mm/hugetlb: Allow runtime allocation of 16G.") That was done | |
15 | to enable 16G allocation on PowerNV and KVM config. In case of KVM | |
16 | config, we mostly would have the entire guest RAM backed by 16G | |
17 | hugetlb pages for this to work. PAPR do support partial backing of | |
18 | guest RAM with hugepages via ibm,expected#pages node of memory node in | |
19 | the device tree. This means rest of the guest RAM won't be backed by | |
20 | 16G contiguous pages in the host and hence a hash page table insertion | |
21 | can fail in such case. | |
22 | ||
23 | An example error message will look like | |
24 | ||
25 | hash-mmu: mm: Hashing failure ! EA=0x7efc00000000 access=0x8000000000000006 current=readback | |
26 | hash-mmu: trap=0x300 vsid=0x67af789 ssize=1 base psize=14 psize 14 pte=0xc000000400000386 | |
27 | readback[12260]: unhandled signal 7 at 00007efc00000000 nip 00000000100012d0 lr 000000001000127c code 2 | |
28 | ||
29 | This patch address that by preventing runtime allocation of 16G | |
30 | hugepages in LPAR config. To allocate 16G hugetlb one need to kernel | |
31 | command line hugepagesz=16G hugepages=<number of 16G pages> | |
32 | ||
33 | With radix translation mode we don't run into this issue. | |
34 | ||
35 | This change will prevent runtime allocation of 16G hugetlb pages on | |
36 | kvm with hash translation mode. However, with the current upstream it | |
37 | was observed that 16G hugetlbfs backed guest doesn't boot at all. | |
38 | ||
39 | We observe boot failure with the below message: | |
40 | [131354.647546] KVM: map_vrma at 0 failed, ret=-4 | |
41 | ||
42 | That means this patch is not resulting in an observable regression. | |
43 | Once we fix the boot issue with 16G hugetlb backed memory, we need to | |
44 | use ibm,expected#pages memory node attribute to indicate 16G page | |
45 | reservation to the guest. This will also enable partial backing of | |
46 | guest RAM with 16G pages. | |
47 | ||
48 | Fixes: 4ae279c2c96a ("powerpc/mm/hugetlb: Allow runtime allocation of 16G.") | |
49 | Cc: stable@vger.kernel.org # v4.14+ | |
50 | Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> | |
51 | Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> | |
52 | Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
53 | ||
54 | --- | |
55 | arch/powerpc/include/asm/book3s/64/hugetlb.h | 8 ++++++++ | |
56 | 1 file changed, 8 insertions(+) | |
57 | ||
58 | --- a/arch/powerpc/include/asm/book3s/64/hugetlb.h | |
59 | +++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h | |
60 | @@ -55,6 +55,14 @@ static inline pte_t arch_make_huge_pte(p | |
61 | #ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE | |
62 | static inline bool gigantic_page_supported(void) | |
63 | { | |
64 | + /* | |
65 | + * We used gigantic page reservation with hypervisor assist in some case. | |
66 | + * We cannot use runtime allocation of gigantic pages in those platforms | |
67 | + * This is hash translation mode LPARs. | |
68 | + */ | |
69 | + if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled()) | |
70 | + return false; | |
71 | + | |
72 | return true; | |
73 | } | |
74 | #endif |