[PATCH 3/6] 8xx: get rid of _PAGE_HWWRITE dependency in MMU.
Joakim Tjernlund
joakim.tjernlund at transmode.se
Tue Oct 6 10:35:45 EST 2009
Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote on 06/10/2009 01:15:39:
>
> On Tue, 2009-10-06 at 00:55 +0200, Joakim Tjernlund wrote:
> > > Sure but if dirty is cleared by the kernel, then you also need to
> > remove
> > > write permission in the TLB or it will miss setting dirty on the
> > next
> > > store to the page.
> >
> > Dirty map to HW changed bit so if kernel clears it, the next
> > store will trap to DTLB error. There I will check RW and clear it
> > again
> > without trapping to C. Is that OK? Not if I read you correcly below ..
>
> 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?
> 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?
>
> I think I need to get myself an 8xx manual and figure out what that damn
> MMU actually does :-)
Please do, get the mpc862 users manual :)
>
> > No it's really !(RW _AND_ DIRTY) -> no store permitted, and
> >
> > .. hmm, I don't do that. I should do a
> > if ( store && !(pte & (RW | DIRTY))
> > goto DSI
> > in DTLB error?
>
> Well, if the HW does the test of DIRTY, then it's fine, as you seem to
> suggest above. _something_ needs to do it, either SW or HW, ie, we need
> to catch any attempt to store to a non-dirty page to set dirty.
Yes, I think I do this.
>
> > > !(PRESENT _AND_ ACCESSED) -> no access permitted.
> >
> > Yes, how about those pinned kernel ptes. Do they have ACCESSED from
> > start?
>
> They should.
>
> Cheers,
> Ben.
>
>
>
>
More information about the Linuxppc-dev
mailing list