On Fri, 2019-07-12 at 23:09 +1000, Michael Ellerman wrote: > Suraj Jitindar Singh <sjitindarsi...@gmail.com> writes: > > The virtual real mode addressing (VRMA) mechanism is used when a > > partition is using HPT (Hash Page Table) translation and performs > > real mode accesses (MSR[IR|DR] = 0) in non-hypervisor mode. In this > > mode effective address bits 0:23 are treated as zero (i.e. the > > access > > is aliased to 0) and the access is performed using an implicit 1TB > > SLB > > entry. > > > > The size of the RMA (Real Memory Area) is communicated to the guest > > as > > the size of the first memory region in the device tree. And because > > of > > the mechanism described above can be expected to not exceed 1TB. In > > the > > event that the host erroneously represents the RMA as being larger > > than > > 1TB, guest accesses in real mode to memory addresses above 1TB will > > be > > aliased down to below 1TB. This means that a memory access > > performed in > > real mode may differ to one performed in virtual mode for the same > > memory > > address, which would likely have unintended consequences. > > > > To avoid this outcome have the guest explicitly limit the size of > > the > > RMA to the current maximum, which is 1TB. This means that even if > > the > > first memory block is larger than 1TB, only the first 1TB should be > > accessed in real mode. > > > > Signed-off-by: Suraj Jitindar Singh <sjitindarsi...@gmail.com> > > I added: > > Fixes: c3ab300ea555 ("powerpc: Add POWER9 cputable entry") > Cc: sta...@vger.kernel.org # v4.6+ > > > Which is not exactly correct, but probably good enough?
I think we actually want: Fixes: c610d65c0ad0 ("powerpc/pseries: lift RTAS limit for hash") Which is what actually caused it to break and for the issue to present itself. > > cheers > > > diff --git a/arch/powerpc/mm/book3s64/hash_utils.c > > b/arch/powerpc/mm/book3s64/hash_utils.c > > index 28ced26f2a00..4d0e2cce9cd5 100644 > > --- a/arch/powerpc/mm/book3s64/hash_utils.c > > +++ b/arch/powerpc/mm/book3s64/hash_utils.c > > @@ -1901,11 +1901,19 @@ void > > hash__setup_initial_memory_limit(phys_addr_t first_memblock_base, > > * > > * For guests on platforms before POWER9, we clamp the it > > limit to 1G > > * to avoid some funky things such as RTAS bugs etc... > > + * On POWER9 we limit to 1TB in case the host erroneously > > told us that > > + * the RMA was >1TB. Effective address bits 0:23 are > > treated as zero > > + * (meaning the access is aliased to zero i.e. addr = addr > > % 1TB) > > + * for virtual real mode addressing and so it doesn't make > > sense to > > + * have an area larger than 1TB as it can't be addressed. > > */ > > if (!early_cpu_has_feature(CPU_FTR_HVMODE)) { > > ppc64_rma_size = first_memblock_size; > > if (!early_cpu_has_feature(CPU_FTR_ARCH_300)) > > ppc64_rma_size = min_t(u64, > > ppc64_rma_size, 0x40000000); > > + else > > + ppc64_rma_size = min_t(u64, > > ppc64_rma_size, > > + 1UL << > > SID_SHIFT_1T); > > > > /* Finally limit subsequent allocations */ > > memblock_set_current_limit(ppc64_rma_size); > > -- > > 2.13.6