how to check for "optional" ppc chip features (MSR_BE)

how to check for "optional" ppc chip features (MSR_BE)

[Roland McGrath]

I've been looking at PowerISA_Public.pdf that I downloaded from some ppc
site.  It describes various things as "need not be supported on all
implementations", for example the MSR_BE bit.  Is there a generic way to
detect if such a feature is supported, or a known table of models that
support features, or what?

Right now I'm considering MSR_BE (branch tracing).  I have a patch to use
this (arch_has_block_step, enabling a PTRACE_SINGLEBLOCK).  The only
machine handy to test is a Mac G5 (PPC970FX, 3.0 (pvr 003c 0300)).  I know
this chip supports MSR_BE.  But that's only because I wrote an affirmative
test case and tried it and saw it work right.  

Before submitting the kernel changes, I want to get the CPU model
conditionalization correct (a runtime check on some feature bit mask is
fine here, if CONFIG_* alone does not indicate for sure).


Thanks,
Roland

Re: how to check for "optional" ppc chip features (MSR_BE)

[Kumar Gala]

On May 1, 2008, at 8:21 PM, Roland McGrath wrote:

> I've been looking at PowerISA_Public.pdf that I downloaded from some  
> ppc
> site.  It describes various things as "need not be supported on all
> implementations", for example the MSR_BE bit.  Is there a generic  
> way to
> detect if such a feature is supported, or a known table of models that
> support features, or what?
>
> Right now I'm considering MSR_BE (branch tracing).  I have a patch  
> to use
> this (arch_has_block_step, enabling a PTRACE_SINGLEBLOCK).  The only
> machine handy to test is a Mac G5 (PPC970FX, 3.0 (pvr 003c 0300)).   
> I know
> this chip supports MSR_BE.  But that's only because I wrote an  
> affirmative
> test case and tried it and saw it work right.

Look at arch/powerpc/kernel/cputable.c to see how we handle issues  
like this.

> Before submitting the kernel changes, I want to get the CPU model
> conditionalization correct (a runtime check on some feature bit mask  
> is
> fine here, if CONFIG_* alone does not indicate for sure).

I believe all PPC that implement MSR[SE] also support MSR[BE].  The  
"Book-E" class PPCs have a different mechanism to single branch  
completion (these are embedded PPC products).

I've been working on changes related to the Book-E class machines and  
would be happy to try and port what you're looking over.

- k

Re: how to check for "optional" ppc chip features (MSR_BE)

[Benjamin Herrenschmidt]

On Thu, 2008-05-01 at 22:48 -0500, Kumar Gala wrote:
> 
> Look at arch/powerpc/kernel/cputable.c to see how we handle issues  
> like this.
> 

Oh and classic pitfall: If you define a new feature bit, make sure
CPU_FTRS_POSSIBLE is updated to contain it in cputable.h

Also, It may not be totally clear, but:

PPC_FEATURE_* are exposed to userspace via AT_HWCAP

CPU_FTR_* are kernel internal (and can be used for runtime patching of
assembly code).

Ben.

Re: how to check for "optional" ppc chip features (MSR_BE)

[Roland McGrath]

> Oh and classic pitfall: If you define a new feature bit, make sure
> CPU_FTRS_POSSIBLE is updated to contain it in cputable.h

Yeah, all that stuff I could figure out as needed.  What I really meant
was, where is the big official table of which chips behave which ways that
you base all code that on?  Actually, I don't really care as long as you
all are happy to be responsible for figuring out what matters.  With the
patch I posted to use MSR_BE, I took Kumar Gala's word as gospel that all
the chips on which we use MSR_SE also have MSR_BE.  If that's not right,
then I hope you'd like to pick a feature bit, populate the tables, etc.,
and fix the definition of arch_has_block_step() as appropriate.


Thanks,
Roland

Re: how to check for "optional" ppc chip features (MSR_BE)

[Benjamin Herrenschmidt]

On Sun, 2008-05-04 at 16:12 -0700, Roland McGrath wrote:
> > Oh and classic pitfall: If you define a new feature bit, make sure
> > CPU_FTRS_POSSIBLE is updated to contain it in cputable.h
> 
> Yeah, all that stuff I could figure out as needed.  What I really meant
> was, where is the big official table of which chips behave which ways that
> you base all code that on?

There isn't any ...

> Actually, I don't really care as long as you
> all are happy to be responsible for figuring out what matters.  With the
> patch I posted to use MSR_BE, I took Kumar Gala's word as gospel that all
> the chips on which we use MSR_SE also have MSR_BE.  If that's not right,
> then I hope you'd like to pick a feature bit, populate the tables, etc.,
> and fix the definition of arch_has_block_step() as appropriate.

I'll have to check with Paul, we'll scrub the IBM parts, and Kumar can
dbl check the "classic 32" FSL parts.

Ben.

Re: how to check for "optional" ppc chip features (MSR_BE)

[Paul Mackerras]

Roland McGrath writes:

> Yeah, all that stuff I could figure out as needed.  What I really meant
> was, where is the big official table of which chips behave which ways that
> you base all code that on?  Actually, I don't really care as long as you
> all are happy to be responsible for figuring out what matters.  With the
> patch I posted to use MSR_BE, I took Kumar Gala's word as gospel that all
> the chips on which we use MSR_SE also have MSR_BE.  If that's not right,
> then I hope you'd like to pick a feature bit, populate the tables, etc.,
> and fix the definition of arch_has_block_step() as appropriate.

It turns out that the 601 doesn't support MSR_BE.  It looks like all
the "classic" 32-bit implementations after that (603, 604, 7xx, 7xxx)
implemented BE, as do POWER3 and RS64.  I'll check the later 64-bit
processors -- I think they all implement BE.  4xx and Book E have it
in a different form.  I'll let Kumar find out about 8xx and 82xx.

So it looks like we need to define a new feature bit to mean "supports
block-step".  Is this something that userspace will expect to be told
about via the AT_HWCAP entry in the aux vector?

Paul.

Re: how to check for "optional" ppc chip features (MSR_BE)

[Kumar Gala]

On May 13, 2008, at 6:55 AM, Paul Mackerras wrote:

> Roland McGrath writes:
>
>> Yeah, all that stuff I could figure out as needed.  What I really  
>> meant
>> was, where is the big official table of which chips behave which  
>> ways that
>> you base all code that on?  Actually, I don't really care as long  
>> as you
>> all are happy to be responsible for figuring out what matters.   
>> With the
>> patch I posted to use MSR_BE, I took Kumar Gala's word as gospel  
>> that all
>> the chips on which we use MSR_SE also have MSR_BE.  If that's not  
>> right,
>> then I hope you'd like to pick a feature bit, populate the tables,  
>> etc.,
>> and fix the definition of arch_has_block_step() as appropriate.
>
> It turns out that the 601 doesn't support MSR_BE.  It looks like all
> the "classic" 32-bit implementations after that (603, 604, 7xx, 7xxx)
> implemented BE, as do POWER3 and RS64.  I'll check the later 64-bit
> processors -- I think they all implement BE.  4xx and Book E have it
> in a different form.  I'll let Kumar find out about 8xx and 82xx.

it appears 8xx does, and 82xx are just 603 cores so they do.

> So it looks like we need to define a new feature bit to mean "supports
> block-step".  Is this something that userspace will expect to be told
> about via the AT_HWCAP entry in the aux vector?

- k

Re: how to check for "optional" ppc chip features (MSR_BE)

[Roland McGrath]

> So it looks like we need to define a new feature bit to mean "supports
> block-step".  Is this something that userspace will expect to be told
> about via the AT_HWCAP entry in the aux vector?

I don't care to have userland know about it.  I'm just concerned with the
arch_has_block_step() definition being right.  But, you did previously tell
me that userland can set its own MSR_SE via sigreturn or setcontext or
something.  If it can set its own MSR_BE the same way, then perhaps
userland wants to know.


Thanks,
Roland

Re: how to check for "optional" ppc chip features (MSR_BE)

[Kumar Gala]

On May 13, 2008, at 2:33 PM, Roland McGrath wrote:

>> So it looks like we need to define a new feature bit to mean  
>> "supports
>> block-step".  Is this something that userspace will expect to be told
>> about via the AT_HWCAP entry in the aux vector?
>
> I don't care to have userland know about it.  I'm just concerned  
> with the
> arch_has_block_step() definition being right.  But, you did  
> previously tell
> me that userland can set its own MSR_SE via sigreturn or setcontext or
> something.  If it can set its own MSR_BE the same way, then perhaps
> userland wants to know.

Did we close on this, I'm going to test Roland's patch on book-e and  
will post results.

- k