Question regarding the DTLB Miss exceptions

Question regarding the DTLB Miss exceptions

[Bruce_Leonard]

I'm tracking a problem that's leading me through DSI and DTLB miss 
exceptions on an MPC8347 (e300c1 core), and I've come across an oddity 
that I'm hoping someone can explain.

When a DTLB Miss exception can't find a PTE for the virtual address being 
written/read, it dummies up the SPRs for a DSI exception and then calls 
directly into the DSI exception code.  Just before the DTLB miss code 
stores a value into DSISR it sets bit 2, which for a DSI exception is a 
reserved bit and should be cleared.  There's no comment on the code 
(.../arch/powerpc/kernel/head_32.S line 619 of the 2.6.33-rc1 kernel). Can 
anyone tell me why this bit is getting set?

Thanks.

Bruce

Re: Question regarding the DTLB Miss exceptions

[Joakim Tjernlund]

>
> I'm tracking a problem that's leading me through DSI and DTLB miss
> exceptions on an MPC8347 (e300c1 core), and I've come across an oddity
> that I'm hoping someone can explain.
>
> When a DTLB Miss exception can't find a PTE for the virtual address being
> written/read, it dummies up the SPRs for a DSI exception and then calls
> directly into the DSI exception code.  Just before the DTLB miss code
> stores a value into DSISR it sets bit 2, which for a DSI exception is a
> reserved bit and should be cleared.  There's no comment on the code
> (.../arch/powerpc/kernel/head_32.S line 619 of the 2.6.33-rc1 kernel). Can
> anyone tell me why this bit is getting set?

Probably for generic handling in do_page_fault()

  Jocke

Re: Question regarding the DTLB Miss exceptions

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

On Mon, 2010-03-29 at 23:24 -0700, Bruce_Leonard@selinc.com wrote: 
> I'm tracking a problem that's leading me through DSI and DTLB miss 
> exceptions on an MPC8347 (e300c1 core), and I've come across an oddity 
> that I'm hoping someone can explain.
> 
> When a DTLB Miss exception can't find a PTE for the virtual address being 
> written/read, it dummies up the SPRs for a DSI exception and then calls 
> directly into the DSI exception code.  Just before the DTLB miss code 
> stores a value into DSISR it sets bit 2, which for a DSI exception is a 
> reserved bit and should be cleared.  There's no comment on the code 
> (.../arch/powerpc/kernel/head_32.S line 619 of the 2.6.33-rc1 kernel). Can 
> anyone tell me why this bit is getting set?

You mean:

616 DataAddressInvalid:
 617         mfspr   r3,SPRN_SRR1
 618         rlwinm  r1,r3,9,6,6     /* Get load/store bit */
 619         addis   r1,r1,0x2000                                               
 620         mtspr   SPRN_DSISR,r1

Is it trying to set DSISR_ISSTORE?

#define   DSISR_ISSTORE         0x02000000      /* access was a store */    


cheers 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Question regarding the DTLB Miss exceptions

[Bruce_Leonard]

> > When a DTLB Miss exception can't find a PTE for the virtual address 
being 
> > written/read, it dummies up the SPRs for a DSI exception and then 
calls 
> > directly into the DSI exception code.  Just before the DTLB miss code 
> > stores a value into DSISR it sets bit 2, which for a DSI exception is 
a 
> > reserved bit and should be cleared.  There's no comment on the code 
> > (.../arch/powerpc/kernel/head_32.S line 619 of the 2.6.33-rc1 kernel). 
Can 
> > anyone tell me why this bit is getting set?
> 
> You mean:
> 
> 616 DataAddressInvalid:
>  617         mfspr   r3,SPRN_SRR1
>  618         rlwinm  r1,r3,9,6,6     /* Get load/store bit */
>  619         addis   r1,r1,0x2000  
>  620         mtspr   SPRN_DSISR,r1
> 
> Is it trying to set DSISR_ISSTORE?
> 
> #define   DSISR_ISSTORE         0x02000000      /* access was a store */ 
 
> 
Michael,

Thanks for the reply.

I mean line 619 above.  It's setting 0x20000000 (bit 2) in the DSISR. 
0x02000000 (bit 6 or DSISR_ISSTORE) is already set because it's a DTLB 
Data Store Miss Exception.  But 0x20000000 is meaningless for the DSI 
Exception about to be called.  According to the data sheet, it's supposed 
to be cleared.  Someone wrote code to explicitly set a bit in the DSISR 
that has no meaning in the PPC architecture.  So I assume it's being 
overloaded for some purpose, but I can't glean that purpose from the code. 
 Equally perplexing to me is the following line of code from the DSI 
Exception code:

andis.  r0,r10,0xa470   /* weird error? */

It's checking to see if the following bits of DSISR are set:
0 - set by DTLB miss if no hash table entry group is found
2 - an invalid bit
5 - an invalid bit
9 - set if breakpoint match
10 - invalid bit
11 - set if the instruction is an ecwix or ecowx and EAR[E] = 0

So it's checking to see if three bits not defined by the PPC architecture 
are set and calling it a "weird error".  What the heck does that mean, a 
"weird error"?  Obviously overloaded bits used for some totally 
undocumented purpose that I can't figure out from the code and I'm just 
trying to understand what they're used for to see if it's related to my 
problem.

Bruce

Re: Question regarding the DTLB Miss exceptions

[Benjamin Herrenschmidt]

On Thu, 2010-04-08 at 12:33 -0700, Bruce_Leonard@selinc.com wrote:

(CC'ing Paulus who wrote that code ages ago)

> > 616 DataAddressInvalid:
> >  617         mfspr   r3,SPRN_SRR1
> >  618         rlwinm  r1,r3,9,6,6     /* Get load/store bit */
> >  619         addis   r1,r1,0x2000  
> >  620         mtspr   SPRN_DSISR,r1
> > 
> > Is it trying to set DSISR_ISSTORE?
> > 
> > #define   DSISR_ISSTORE         0x02000000      /* access was a store */ 
>  
> > 
> Michael,
> 
> Thanks for the reply.
> 
> I mean line 619 above.  It's setting 0x20000000 (bit 2) in the DSISR. 
> 0x02000000 (bit 6 or DSISR_ISSTORE) is already set because it's a DTLB 
> Data Store Miss Exception.  But 0x20000000 is meaningless for the DSI 
> Exception about to be called.  According to the data sheet, it's supposed 
> to be cleared.  Someone wrote code to explicitly set a bit in the DSISR 
> that has no meaning in the PPC architecture.

I agree that setting a bit in DSISR is very very fishy... however it
works and it's not like there was going to be loads of new 603's so I
assume it's no big deal. As to the meaning of the bits, see below...

>   So I assume it's being 
> overloaded for some purpose, but I can't glean that purpose from the code. 
>  Equally perplexing to me is the following line of code from the DSI 
> Exception code:
> 
> andis.  r0,r10,0xa470   /* weird error? */
> 
> It's checking to see if the following bits of DSISR are set:
> 0 - set by DTLB miss if no hash table entry group is found

No. 0 means we hit a direct store segment. This is a historical feature
of the architecture which we don't use, so should not happen.

> 2 - an invalid bit

Not sure what 2 is about.

> 5 - an invalid bit

Nah, that is set on some processors such as 604 when doing a lwarx/stwcx
with W=1 or such forbidden settings, though I don't remember if it was
architected back then.

> 9 - set if breakpoint match
> 10 - invalid bit

Nah, that is set when missing on segments.

> 11 - set if the instruction is an ecwix or ecowx and EAR[E] = 0
>
> So it's checking to see if three bits not defined by the PPC architecture 
> are set and calling it a "weird error".  What the heck does that mean, a 
> "weird error"?

Nah. It's a bad name. It means it's an error that is either something we
don't support (like direct store) or something that doesn't need to go
through hash_page, such as a breakpoint match.

I suppose we should probably also test for bit 6 (protection violation)
since that will always land into do page fault. That would mean removing
the code to set DIRTY in the hash code and rely on the C code to do it,
and thus speeding up page faults a bit, but I don't see that as being a
big deal.

>   Obviously overloaded bits used for some totally 
> undocumented purpose that I can't figure out from the code and I'm just 
> trying to understand what they're used for to see if it's related to my 
> problem. 

I missed the earlier discussion, what is your problem ?

Cheers,
Ben.

Re: Question regarding the DTLB Miss exceptions

[Bruce_Leonard]

> > 
> > It's checking to see if the following bits of DSISR are set:
> > 0 - set by DTLB miss if no hash table entry group is found
> 
> No. 0 means we hit a direct store segment. This is a historical feature
> of the architecture which we don't use, so should not happen.
> 

Sorry, would have helped if I had specified the processor; we're using an 
MPC8347, so it's an e300c1 core.  Also, my fat-fingering of the keyboard 
got me on this one - bit 0 on the e300 should be cleared.  I put in bit 
1's definition by mistake in my last email.

> > 2 - an invalid bit
> 
> Not sure what 2 is about.

Yeah, and that's the one I'm trying to figure out why the DTLB Miss on 
Store exception code is setting before calling the DSI exception code :).

> > are set and calling it a "weird error".  What the heck does that mean, 
a 
> > "weird error"?
> 
> Nah. It's a bad name. It means it's an error that is either something we
> don't support (like direct store) or something that doesn't need to go
> through hash_page, such as a breakpoint match.
> 

Thanks, that actually helps, knowing that what's being done is determining 
reasons to call hash_page or not.  Also knowing (which I suppose I should 
have figured out earlier) that some of the bits in DSISR are not defined 
for the e300c1 core but that the code is designed to support 
implementations that DO define those bits helps make sense of what I'm 
looking at.

> 
> I missed the earlier discussion, what is your problem ?
> 

Well, the problem I'm having is really irrelevant to the question at hand. 
 My original question to the list was "why is the DTLB Store Miss 
exception setting bit two of the DSISR (an invalid bit according to the 
architecture) before calling the DSI exception?".

Thanks for the explanations!

Bruce