LinuxPPC-Dev Archive on
 help / Atom feed
From: Nicholas Piggin <>
To: "Aneesh Kumar K.V" <>,,
Subject: Re: [PATCH] powerpc/book3s/mm: Clear MMU_FTR_HPTE_TABLE when radix is enabled.
Date: Fri, 17 May 2019 19:21:54 +1000
Message-ID: <1558084576.9an48zl8ss.astroid@bobo.none> (raw)
In-Reply-To: <>

Aneesh Kumar K.V's on May 16, 2019 11:36 pm:
> On 5/16/19 10:34 AM, Nicholas Piggin wrote:
>> Aneesh Kumar K.V's on May 14, 2019 4:02 pm:
>>> Avoids confusion when printing Oops message like below
>>>   Faulting instruction address: 0xc00000000008bdb4
>>>   Oops: Kernel access of bad area, sig: 11 [#1]
>>>   LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>>> Either ibm,pa-features or ibm,powerpc-cpu-features can be used to enable the
>>> MMU features. We don't clear related MMU feature bits there. We use the kernel
>>> commandline to determine what translation mode we want to use and clear the
>>> HPTE or radix bit accordingly. On LPAR we do have to renable HASH bit if the
>>> hypervisor can't do radix.
>> Well we have the HPTE feature: the CPU supports hash MMU mode. It's
>> just the the kernel is booted in radix mode.
> We are not using mmu_features to indicate the capability of the hardware 
> right? ie, mmu_features is an indication of current running config.

It's kind of both.

> We 
> set MMU_FTR_TYPE_RADIX if the kernel is running in radix translation 
> mode and on similar lines we should set MMU_FTR_HPTE_TABLE if the kernel 
> is running in only hash translation mode. Whether the hardware support 
> these translation mode is different from which mode is currently used.

I don't see why that logic follows. We have MMU_FTR_TYPE_RADIX to
determine if we are running in radix or HPT mode, why do we need
another bit for the same thing?

>> Could make a difference for KVM, if it will support an HPT guest or
>> not.
> kvm should not depend on MMU_FTR_HPTE_TABLE to identify whether the 
> hardware supports hash page table translation.

Why not though?

> I don't think we do that.

It doesn't, but the point is the bit is kind of useful now (in
theory if you wanted to do something like that), but if you just
make it an inverse of the current mode bit we already have, then
it's useless.

Point is, just use the existing radix MMU selection bit that we
use everywhere else to fix the problem. If that finishes off the
only 64-bit users of the bit and you want to get rid of that as
well I'm fine with that too.


      reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14  6:02 Aneesh Kumar K.V
2019-05-16  5:04 ` Nicholas Piggin
2019-05-16 13:36   ` Aneesh Kumar K.V
2019-05-17  9:21     ` Nicholas Piggin [this message]

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1558084576.9an48zl8ss.astroid@bobo.none \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LinuxPPC-Dev Archive on

Archives are clonable:
	git clone --mirror linuxppc-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linuxppc-dev linuxppc-dev/ \
	public-inbox-index linuxppc-dev

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox