Benjamin Herrenschmidt wrote: >> arch/powerpc/platfroms/ps3/htab.c:ps3_hpte_updatepp() uses `htab[slot].v'. > > Ok, that leaves us with 2 options: > > - Change ps3_hpte_updatepp() to not read from the hash table via that > mapping (ie, do you have an LV1 call to read an HPTE ? Do you measure > any significant performance loss using that instead ? updatepp shouldn't > be something called -that- often).
Yes, we have lv1_read_htab_entries(). Mokuno-san started some work to convert to using it and removing the htab mapping: http://git.kernel.org/?p=linux/kernel/git/geoff/ps3-linux-patches.git;a=blob;f=ps3-wip/ps3-htab-rework.diff;hb=HEAD Unfortunately, this week Mokuno-san is on holiday, and I am busy preparing for SIGGRAPH (next week). > - Add a way to setup HPTEs using 3 PPP bits. I'm not going to implement > that for the main hash code just yet though (the assembly) but it might > be possible to implement it specifically for mappings bolted. That > means it would only work when the mapping is done early but on PS3, we > know that the hash table is always mapped early. > > The later would be a matter of taking my htab_convert_pte_flags() function > and making it capable, when _PAGE_USER is _not_ set and _PAGE_RW is not > set neither, to set PPP to 110. > > You could do that by adding: > > if (!(pteflags & (_PAGE_USER | _PAGE_RW))) > rflags |= (1 << 1) | (1 << 63); > > Dbl check that the resulting mapping isn't accessible to user space though. If we can't remove the htab mapping with lv1_read_htab_entries(), I'll look into this way. -Geoff _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
