On Thu, 2009-10-08 at 00:08 +0200, Joakim Tjernlund wrote: > > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote on 07/10/2009 > 23:14:52: > > > > On Wed, 2009-10-07 at 22:46 +0200, Joakim Tjernlund wrote: > > > > > + andi. r11, r10, _PAGE_USER | _PAGE_ACCESSED > > > + cmpwi cr0, r11, _PAGE_USER | _PAGE_ACCESSED > > > + bne- cr0, 2f > > > > Did you mean _PAGE_PRESENT | _PAGE_ACCESSED ? > > > > > +2: > > > + mfspr r11, SRR1 > > > + rlwinm r11, r11, 0, 5, 3 /* clear guarded */ > > > + mtspr SRR1, r11 > > > > What is the above for ? > > TLB Miss will set that bit unconditionally and that is > the same bit as protection error in TLB error.
And ? Big deal :-) IE. Once you get to InstructionAccess, it doesn't matter if that bit is set, does it ? > Lets start simple, shall we? :) > Anyhow, I looked some more at that and I don't the best thing is > to use shifts. All bits are correct if you invert RW and add an exception > for extended coding. Right, as long as you avoid doing a conditional branch :-) > Because if you go to C with a protection fault, you are in trouble. Why ? > So deal with it here. Now, I got another idea too that will make this go away > if it work out I don't understand your point about protection faults. You should be able to go straight to C with -anything-, that's what I do for all other platforms. Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
