linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
To: Michael Ellerman <mpe@ellerman.id.au>, linuxppc-dev@lists.ozlabs.org
Cc: kvm-ppc@vger.kernel.org, david@gibson.dropbear.id.au
Subject: Re: [PATCH] powerpc: mm: Limit rma_size to 1TB when running without HV mode
Date: Mon, 15 Jul 2019 11:58:24 +1000	[thread overview]
Message-ID: <1563155904.2145.1.camel@gmail.com> (raw)
In-Reply-To: <87o91ze6wx.fsf@concordia.ellerman.id.au>

On Fri, 2019-07-12 at 23:09 +1000, Michael Ellerman wrote:
> Suraj Jitindar Singh <sjitindarsingh@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 <sjitindarsingh@gmail.com>
> 
> I added:
> 
> Fixes: c3ab300ea555 ("powerpc: Add POWER9 cputable entry")
> Cc: stable@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

  reply	other threads:[~2019-07-15  2:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10  5:20 [PATCH] powerpc: mm: Limit rma_size to 1TB when running without HV mode Suraj Jitindar Singh
2019-07-10  7:32 ` Satheesh Rajendran
2019-07-10 14:21 ` David Gibson
2019-07-12 13:09 ` Michael Ellerman
2019-07-15  1:58   ` Suraj Jitindar Singh [this message]
2019-07-15  2:23     ` Michael Ellerman
2019-07-18 13:56 ` 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=1563155904.2145.1.camel@gmail.com \
    --to=sjitindarsingh@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /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).