mapping memory in 0xb space

[Igor Grobman]

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.
> >



Thanks,
Igor