Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote on 06/10/2009 02:34:15: > > On Tue, 2009-10-06 at 01:35 +0200, Joakim Tjernlund wrote: > > > > > Well, if the HW has the ability to enforce trap when store with ! > > DIRTY, > > > > Yes, provided that the kernel invalidates the TLB too so the next > > access > > will provoke a TLB Miss, which will then provoke a TLB error. The TLB > > error routine checks VALID, RW and USER(if not a kernel access), then > > sets > > ACCESSED & DIRTY and writes the TLB(RPN reg). > > > > Perhaps the missing invalidate is haunting us here? > > No, the kernel will invalidate when clearing dirty or accessed, I don't > think that's our problem. > > This is still all inefficient, we end up basically with two traps.
Yes, but once the 2 traps is over, it gets much cheaper plus I don't get a choice, see below. > > 8xx provides backup GPRs when doing TLB misses ? What does it cost to > jump out of a TLB miss back into "normal" context ? Nope, there is just one TLB scratch register. I have been meaning to ask you about SPRG2, it seems unused? There is a leftover from 2.4 that inits G2 to something but the it appears unused otherwise. > > IE. What I do on 440 is I set a mask of required bits, basically > _PAGE_PRESENT | _PAGE_ACCESSED is the base. The DTLB miss also sticks > in _PAGE_RW | _PAGE_DIRTY when it's a store fault. Yes, I would too but TLB Miss knows nothing about load/store, protection etc. because DSISR isn't set. So I cannot see any other way than the TLB Error way. > > Then, I andc. the PTE value off that mask, and if the result is non-0 > (which means one of the required bits is missing), I get out of the TLB > miss immediately and go to the data (or instruction) access interrupt. > > Once you've done that, you should be able to have data and instruction > access go straight to C. Missing _PAGE_ACCESSED and _PAGE_DIRTY are > going to be fixed up by generic code. > > > > then that's fine, just map it that way, but you shouldn't have to > > handle > > > it in the DTLB error neither, the kernel will fix it up for you in > > > handle_pte_fault(). > > > > Does not all ppc have the Changed bit? > > No. BookE doesn't. But I guess BookE knows if it is a load or store in TLB Miss? Then it can emulate changed bit I guess. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev