mapping memory in 0xb space
igor at cs.wisc.edu
Wed Oct 6 03:45:47 EST 2004
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?
> > > You may have seen the comment in do_slb_bolted which claims to permit
> > > a full 32-bits of ESID - it's wrong. The code doesn't mask the ESID
> > > down to 13 bits as get_kernel_vsid() does, but it probably should - an
> > > overlarge ESID will cause collisions with VSIDs from entirely
> > > different address places, which would be a Bad Thing.
> > This must be happening, although I would still like to know why it
> > misbehaves even within the valid VSID range.
> > >
> > > Actually, you should be able to allow ESIDs of up to 21 bits there (36
> > > bit VSID - 15 bits of "context"). But you will need to make sure
> > > get_kernel_vsid(), or whatever you're using to calculate the VAs for
> > > the hash HPTEs is updated to match - at the moment I think it will
> > > mask down to 13 bits. I'm not sure if that will get you sufficiently
> > > close to 0xc0... for your purposes.
More information about the Linuxppc64-dev