44x bug: funny TLB writes?

44x bug: funny TLB writes?

[Hollis Blanchard]

I seem to have come across a strange bug while doing KVM development. It
seems that the final tlbwe in finish_tlb (head_44x.S) is actually
leaking RPN bits into the "attribute" word.

When I set a breakpoint there and press enter on the serial console, I
see r12=ef600703, which is the physical address of the UART on this chip
(440EP), plus the correct permission bits at the bottom.

Am I crazy? I'm not really looking to step through that assembly right
now... Clearly (current) hardware is just ignoring these errant writes,
but it should be fixed.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: 44x bug: funny TLB writes?

[David Gibson]

On Thu, Sep 20, 2007 at 10:34:12PM -0500, Hollis Blanchard wrote:
> I seem to have come across a strange bug while doing KVM development. It
> seems that the final tlbwe in finish_tlb (head_44x.S) is actually
> leaking RPN bits into the "attribute" word.
> 
> When I set a breakpoint there and press enter on the serial console, I
> see r12=ef600703, which is the physical address of the UART on this chip
> (440EP), plus the correct permission bits at the bottom.
> 
> Am I crazy? I'm not really looking to step through that assembly right
> now... Clearly (current) hardware is just ignoring these errant writes,
> but it should be fixed.

A quick glance at the code suggests this is indeed wrong.  Hurrah.
Another reason to rewrite the 44x tlb miss handling.

PS.  "errant" and "error" are not cognate, even if the chip doc
writers think so...

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: 44x bug: funny TLB writes?

[Hollis Blanchard]

On Fri, 2007-09-21 at 15:42 +1000, David Gibson wrote:
> On Thu, Sep 20, 2007 at 10:34:12PM -0500, Hollis Blanchard wrote:
> > I seem to have come across a strange bug while doing KVM development. It
> > seems that the final tlbwe in finish_tlb (head_44x.S) is actually
> > leaking RPN bits into the "attribute" word.
> > 
> > When I set a breakpoint there and press enter on the serial console, I
> > see r12=ef600703, which is the physical address of the UART on this chip
> > (440EP), plus the correct permission bits at the bottom.
> > 
> > Am I crazy? I'm not really looking to step through that assembly right
> > now... Clearly (current) hardware is just ignoring these errant writes,
> > but it should be fixed.
> 
> A quick glance at the code suggests this is indeed wrong.  Hurrah.
> Another reason to rewrite the 44x tlb miss handling.

Just a quick fix would be fine too... ;)

I'm just glad it's not a KVM bug, because when I dumped the TLB state
and saw bizarre values I was getting really worried.

> PS.  "errant" and "error" are not cognate, even if the chip doc
> writers think so...

According to Merriam Webster, errant 2c is "c : behaving wrongly <an
errant child>", so I'm OK with it.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: 44x bug: funny TLB writes?

[David Gibson]

On Fri, Sep 21, 2007 at 01:38:34AM -0500, Hollis Blanchard wrote:
> On Fri, 2007-09-21 at 15:42 +1000, David Gibson wrote:
> > On Thu, Sep 20, 2007 at 10:34:12PM -0500, Hollis Blanchard wrote:
> > > I seem to have come across a strange bug while doing KVM development. It
> > > seems that the final tlbwe in finish_tlb (head_44x.S) is actually
> > > leaking RPN bits into the "attribute" word.
> > > 
> > > When I set a breakpoint there and press enter on the serial console, I
> > > see r12=ef600703, which is the physical address of the UART on this chip
> > > (440EP), plus the correct permission bits at the bottom.
> > > 
> > > Am I crazy? I'm not really looking to step through that assembly right
> > > now... Clearly (current) hardware is just ignoring these errant writes,
> > > but it should be fixed.
> > 
> > A quick glance at the code suggests this is indeed wrong.  Hurrah.
> > Another reason to rewrite the 44x tlb miss handling.
> 
> Just a quick fix would be fine too... ;)

I suppose.

> I'm just glad it's not a KVM bug, because when I dumped the TLB state
> and saw bizarre values I was getting really worried.
> 
> > PS.  "errant" and "error" are not cognate, even if the chip doc
> > writers think so...
> 
> According to Merriam Webster, errant 2c is "c : behaving wrongly <an
> errant child>", so I'm OK with it.

Good heavens.  No such usage mentioned in the Shorter OED, only as in
"knight errant".  You Americans and your strange language :-p.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: 44x bug: funny TLB writes?

[Hollis Blanchard]

On Fri, 2007-09-21 at 15:42 +1000, David Gibson wrote:
> On Thu, Sep 20, 2007 at 10:34:12PM -0500, Hollis Blanchard wrote:
> > I seem to have come across a strange bug while doing KVM development. It
> > seems that the final tlbwe in finish_tlb (head_44x.S) is actually
> > leaking RPN bits into the "attribute" word.
> > 
> > When I set a breakpoint there and press enter on the serial console, I
> > see r12=ef600703, which is the physical address of the UART on this chip
> > (440EP), plus the correct permission bits at the bottom.
> > 
> > Am I crazy? I'm not really looking to step through that assembly right
> > now... Clearly (current) hardware is just ignoring these errant writes,
> > but it should be fixed.
> 
> A quick glance at the code suggests this is indeed wrong.  Hurrah.
> Another reason to rewrite the 44x tlb miss handling.

Actually it's slightly worse than I thought. Not only are we setting "0"
bits in the TLB word, I'm also seeing mappings like this:

pid      word0    word1    word2
00000001 7fe4f210 00209000 00200349

That means WIMG=0011, which seems inappropriate for userspace mappings.
(Oh and we're also writing to the only reserved bit in word2.)

-- 
Hollis Blanchard
IBM Linux Technology Center