Re: [PATCH] arch/powerpc: advertise ISA2.07, HTM, DSCR, EBB and ISEL bits in HWCAP2

From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org,
	Michael R Meissner <mrmeissn@us.ibm.com>,
	Steve Munroe <sjmunroe@us.ibm.com>,
	Peter Bergner <bergner@us.ibm.com>,
	Ryan Arnold <ryanarn@us.ibm.com>,
	Michael Neuling <michael.neuling@au1.ibm.com>
Subject: Re: [PATCH] arch/powerpc: advertise ISA2.07, HTM, DSCR, EBB and ISEL bits in HWCAP2
Date: Tue, 7 May 2013 13:33:47 -0700	[thread overview]
Message-ID: <20130507203346.GA7307@linux.vnet.ibm.com> (raw)
In-Reply-To: <1367876228.15842.62.camel@pasglop>

On 07.05.2013 [07:37:08 +1000], Benjamin Herrenschmidt wrote:
> On Mon, 2013-05-06 at 09:38 -0500, Ryan Arnold wrote:
> > My understanding was that these bits being 'on' is an indication of
> > what features the hardware supports (or what the kernel emulates) and
> > a not an indication of whether that facility is currently enabled or
> > not.  If the hardware supports a particular feature but it is not
> > enabled I'd expect that user-space usage of that feature would cause
> > the kernel to trap on a facility availability exception (which is how
> > Altivec/VMX is implemented, being defaulted to turned off).
> 
> Right but the discussion is about whether we should expose the bits
> when the kernel doesn't have the ability to handle the feature :-)
> 
> IE. We need to remove the HTM feature if the kernel is compiled without
> transactional memory support.
> 
> Similarily, Nish, you may need to check that we remove those bits if
> pHyp has the partition in a mode that doesn't support them (P7
> compatibility for example) for migration purposes.

Yep, I'll need to talk with Mikey about this part. Will be a follow-on
patch if needed. Minimally, the bit defines will stay the same, which is
the important part to get going right now.

Thanks,
Nish