mapping memory in 0xb space

[David Gibson]

On Tue, Oct 05, 2004 at 12:45:47PM -0500, Igor Grobman wrote:
> One more followup on this issue, since I do have the base code working
> now.  The problem was in the fact that do_slb_bolted code sets the large
> page bit in the SLB entry, but my code (and particularly hpte_insert code)
> did not insert a proper large page mapping.
> 
> 
> On Fri, 1 Oct 2004, David Gibson wrote:
> > On Wed, Sep 29, 2004 at 12:14:08AM -0500, Igor Grobman wrote:
> > > On Wed, 29 Sep 2004, David Gibson wrote:
> > >
> > > > On Tue, Sep 28, 2004 at 01:52:16PM -0500, Igor Grobman wrote:
> > > > > On Tue, 28 Sep 2004, David Gibson wrote:
> > > As for why I thought 0xbff would work,  I reasoned that
> > > since the highest bits are masked out in get_kernel_vsid(), and since
> > > nobody else is using the 0xb region, it doesn't matter if I get a VSID
> > > that is the same as some other VSID in 0xb region.  However, I did not
> > > consider the bug in do_slb_bolted that you describe below.
> >
> > Yes, with that bug the collision can be with a segment anywhere, not
> > just in the 0xb region.
> >
> 
> I am not convinced anymore.  The lower 36 bits of the ordinal are still
> the same in do_slb_bolted and get_kernel_vsid.  Multiplying the ordinal
> by the 36-bit randomizer should produce the same lower 36 bits whether or
> not the upper bits are different.  do_slb_bolted eventually clears the
> upper 28 bits, before using the VSID.  I no longer think there can be
> a conflict outside the 0xb region.  Is my reasoning correct?

Ah, yes, I think it is.  Sorry, I guess I wasn't thinking very clearly
when I decided the collisions could be anywhere.

-- 
David Gibson			| For every complex problem there is a
david AT gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson