From: Nicholas Piggin <npiggin@gmail.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: Nicholas Piggin <npiggin@gmail.com>, kvm-ppc@vger.kernel.org
Subject: [PATCH v2 3/9] powerpc/powernv: Remove real mode access limit for early allocations
Date: Sun, 13 Aug 2017 11:33:40 +1000 [thread overview]
Message-ID: <20170813013346.14002-3-npiggin@gmail.com> (raw)
In-Reply-To: <20170812113416.15978-1-npiggin@gmail.com>
This removes the RMA limit on powernv platform, which constrains
early allocations such as PACAs and stacks. There are still other
restrictions that must be followed, such as bolted SLB limits, but
real mode addressing has no constraints.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/mm/hash_utils_64.c | 24 +++++++++++++++---------
arch/powerpc/mm/pgtable-radix.c | 33 +++++++++++++++++----------------
2 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 7a20669c19e7..d3da19cc4867 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1824,16 +1824,22 @@ void hash__setup_initial_memory_limit(phys_addr_t first_memblock_base,
*/
BUG_ON(first_memblock_base != 0);
- /* On LPAR systems, the first entry is our RMA region,
- * non-LPAR 64-bit hash MMU systems don't have a limitation
- * on real mode access, but using the first entry works well
- * enough. We also clamp it to 1G to avoid some funky things
- * such as RTAS bugs etc...
- */
- ppc64_rma_size = min_t(u64, first_memblock_size, 0x40000000);
+ if (!early_cpu_has_feature(CPU_FTR_HVMODE)) {
+ /*
+ * On virtualized systems, the first entry is our RMA region,
+ * non-LPAR 64-bit hash MMU systems don't have a limitation
+ * on real mode access.
+ *
+ * We also clamp it to 1G to avoid some funky things
+ * such as RTAS bugs etc...
+ */
+ ppc64_rma_size = min_t(u64, first_memblock_size, 0x40000000);
- /* Finally limit subsequent allocations */
- memblock_set_current_limit(ppc64_rma_size);
+ /* Finally limit subsequent allocations */
+ memblock_set_current_limit(ppc64_rma_size);
+ } else {
+ ppc64_rma_size = ULONG_MAX;
+ }
}
#ifdef CONFIG_DEBUG_FS
diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index 671a45d86c18..61ca17d81737 100644
--- a/arch/powerpc/mm/pgtable-radix.c
+++ b/arch/powerpc/mm/pgtable-radix.c
@@ -598,22 +598,23 @@ void radix__setup_initial_memory_limit(phys_addr_t first_memblock_base,
* physical on those processors
*/
BUG_ON(first_memblock_base != 0);
- /*
- * We limit the allocation that depend on ppc64_rma_size
- * to first_memblock_size. We also clamp it to 1GB to
- * avoid some funky things such as RTAS bugs.
- *
- * On radix config we really don't have a limitation
- * on real mode access. But keeping it as above works
- * well enough.
- */
- ppc64_rma_size = min_t(u64, first_memblock_size, 0x40000000);
- /*
- * Finally limit subsequent allocations. We really don't want
- * to limit the memblock allocations to rma_size. FIXME!! should
- * we even limit at all ?
- */
- memblock_set_current_limit(first_memblock_base + first_memblock_size);
+
+ if (!early_cpu_has_feature(CPU_FTR_HVMODE)) {
+ /*
+ * On virtualized systems, the first entry is our RMA region,
+ * non-LPAR 64-bit hash MMU systems don't have a limitation
+ * on real mode access.
+ *
+ * We also clamp it to 1G to avoid some funky things
+ * such as RTAS bugs etc...
+ */
+ ppc64_rma_size = min_t(u64, first_memblock_size, 0x40000000);
+
+ /* Finally limit subsequent allocations */
+ memblock_set_current_limit(ppc64_rma_size);
+ } else {
+ ppc64_rma_size = ULONG_MAX;
+ }
}
#ifdef CONFIG_MEMORY_HOTPLUG
--
2.13.3
next prev parent reply other threads:[~2017-08-13 1:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-12 11:34 [PATCH v2 0/9] improve early structure allocations (paca, lppaca, etc) Nicholas Piggin
2017-08-13 1:33 ` [PATCH v2 1/9] KVM: PPC: Book3S HV: Fix H_REGISTER_VPA VPA size validation Nicholas Piggin
2017-08-15 11:24 ` Michael Ellerman
2017-08-31 3:41 ` Paul Mackerras
2017-08-13 1:33 ` [PATCH v2 2/9] powerpc/powernv: powernv platform is not constrained by RMA Nicholas Piggin
2017-08-31 11:36 ` [v2, " Michael Ellerman
2017-08-13 1:33 ` Nicholas Piggin [this message]
2017-08-14 12:49 ` [PATCH v2 3/9] powerpc/powernv: Remove real mode access limit for early allocations Michael Ellerman
2017-08-14 13:10 ` Benjamin Herrenschmidt
2017-08-14 14:51 ` Nicholas Piggin
2017-08-14 13:13 ` Benjamin Herrenschmidt
2017-08-15 12:10 ` Nicholas Piggin
2017-08-15 12:48 ` Benjamin Herrenschmidt
2017-08-15 13:02 ` Nicholas Piggin
2017-09-12 10:13 ` Aneesh Kumar K.V
2017-09-12 10:26 ` Benjamin Herrenschmidt
2017-08-13 1:33 ` [PATCH v2 4/9] powerpc/64s/radix: Remove bolted-SLB address limit for per-cpu stacks Nicholas Piggin
2017-08-31 11:36 ` [v2, " Michael Ellerman
2017-08-13 1:33 ` [PATCH v2 5/9] powerpc/64s: Relax PACA address limitations Nicholas Piggin
2017-08-13 1:33 ` [PATCH v2 6/9] powerpc/64s/radix: Do not allocate SLB shadow structures Nicholas Piggin
2017-08-31 11:36 ` [v2, " Michael Ellerman
2017-08-13 1:33 ` [PATCH v2 7/9] powerpc/64s: do not allocate lppaca if we are not virtualized Nicholas Piggin
2017-10-13 22:47 ` Paul Mackerras
2017-10-14 3:54 ` Nicholas Piggin
2017-08-13 1:33 ` [PATCH v2 8/9] powerpc/64: Use a table of paca pointers and allocate pacas individually Nicholas Piggin
2017-08-15 15:50 ` Nicholas Piggin
2017-08-15 17:30 ` kbuild test robot
2017-08-13 1:33 ` [PATCH v2 9/9] powerpc/64: Use a table of lppaca pointers and allocate lppacas individually Nicholas Piggin
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=20170813013346.14002-3-npiggin@gmail.com \
--to=npiggin@gmail.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/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).