mapping memory in 0xb space
david at gibson.dropbear.id.au
Thu Oct 7 11:01:54 EST 2004
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
More information about the Linuxppc64-dev