[Cbe-oss-dev] 64K Page Support for Kexec

[Luke Browning]

On Mon, 2007-03-26 at 07:11 +1000, Benjamin Herrenschmidt wrote:

> > I am confused about the following comment.
> > 
> > /*
> >  * XXX This need fixing based on page size. It's only used by
> >  * native_hpte_clear() for now which needs fixing too so they
> >  * make a good pair...
> >  */
> > static unsigned long slot2va(unsigned long hpte_v, unsigned long slot)
> > {
> >         unsigned long avpn = HPTE_V_AVPN_VAL(hpte_v);
> >         unsigned long va;
> > 
> >         va = avpn << 23;
> > 
> >         if (! (hpte_v & HPTE_V_LARGE)) {
> >                 unsigned long vpi, pteg;
> > 
> >                 pteg = slot / HPTES_PER_GROUP;
> >                 if (hpte_v & HPTE_V_SECONDARY)
> >                         pteg = ~pteg;
> > 
> >                 vpi = ((va >> 28) ^ pteg) & htab_hash_mask;
> > 
> >                 va |= vpi << PAGE_SHIFT;
> >         }
> > 
> >         return va;
> > }
> > 
> > The routine above looks OK to me.  What am I missing?
> 
> A quick look without my brain's math function enabled says it ought to
> be right for 256M segments (we don't quite do 1T segments yet anyway)
> for the native page size (page size == PAGE_SIZE). You may want to
> double-check for non native though.
> 
> For example, you can have 64K pages in the hash table with PAGE_SHIFT
> set to 12 (4k base page size) or 16M pages (the former with the 64K LS
> hack, the later with hugetlbfs), or you can have 16M pages in with a
> PAGE_SHIFT of 16. I'm not sure va |= vpi << PAGE_SHIFT statement is
> correct in that context. Also, for 16M pages, I suppose avpn << 23 is
> correct (doesn't need to mask out the low bit) because the avpn in the
> hash pte already had the low bit clear but it might be worth dbl
> checking.
> 

Thanks.  That is going to require some further research.  I didn't see
where these pages were added to the page table.  Are they in
hash_native_64.c also?

Luke