<html><body>
<p><tt><font size="2">Nishanth Aravamudan <nacc@linux.vnet.ibm.com> wrote on 05/03/2013 06:40:19 PM:<br>
<br>
> Nishanth Aravamudan <nacc@linux.vnet.ibm.com> </font></tt><br>
<tt><font size="2">> 05/03/2013 06:40 PM</font></tt><br>
<tt><font size="2">> <br>
> To</font></tt><br>
<tt><font size="2">> <br>
> Benjamin Herrenschmidt <benh@kernel.crashing.org></font></tt><br>
<tt><font size="2">> <br>
> cc</font></tt><br>
<tt><font size="2">> <br>
> Michael Neuling <michael.neuling@au1.ibm.com>, Michael R Meissner/<br>
> Cambridge/IBM@IBMUS, Steve Munroe/Rochester/IBM@IBMUS, Peter <br>
> Bergner/Rochester/IBM@IBMUS, Ryan Arnold/Rochester/IBM@IBMUS, <br>
> linuxppc-dev@lists.ozlabs.org</font></tt><br>
<tt><font size="2">> <br>
> Subject</font></tt><br>
<tt><font size="2">> <br>
> Re: [PATCH] arch/powerpc: advertise ISA2.07, HTM, DSCR, EBB and ISEL<br>
> bits in HWCAP2</font></tt><br>
<tt><font size="2">> <br>
> On 04.05.2013 [09:23:51 +1000], Benjamin Herrenschmidt wrote:<br>
> > On Fri, 2013-05-03 at 16:19 -0700, Nishanth Aravamudan wrote:<br>
> > > +/* in AT_HWCAP2 */<br>
> > > +#define PPC_FEATURE2_ARCH_2_07 0x80000000<br>
> > > +#define PPC_FEATURE2_HTM 0x40000000<br>
> > > +#define PPC_FEATURE2_DSCR 0x20000000<br>
> > > +#define PPC_FEATURE2_EBB 0x10000000<br>
> > > +#define PPC_FEATURE2_ISEL 0x08000000<br>
> > <br>
> > Should we "adjust" (ie filter out) some of these based<br>
> > on CONFIG_ options (such as transactional memory enabled,<br>
> > EBB supported by the hypervisor, etc...) ?<br>
> <br>
> Err, yeah, that seems reasonable :) However, it seems like glibc uses<br>
> these values rather directly so it knows what bits to check for each<br>
> feature. Therefore, it seems like it would be better to do the<br>
> ifdeffery/checking in the user in cputable.c, but that seems like it<br>
> could get quite complicated.<br>
> <br>
> Would it be ok (I guess I'm asking Ryan & co. here) to have an #ifdef in<br>
> the definition that may or may not mean the bit is set in the aux<br>
> vector, but the bit, if set, would always be the same bit?<br>
</font></tt><br>
<tt><font size="2">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).</font></tt><br>
<br>
<tt><font size="2">Otherwise there's no way I could know whether an ISA [optional] feature is actually available on a particular machine.</font></tt><br>
<br>
<tt><font size="2">And yes, the bits can't change. My usage of hwcap.h has to coincide with the kernel's asm/cputable.h</font></tt><br>
<tt><font size="2">Ryan</font></tt></body></html>