[PATCH 1/5] powerpc/mm: Add MMU features for TLB reservation & Paired MAS registers
Kumar Gala
galak at kernel.crashing.org
Thu Aug 20 07:37:49 EST 2009
On Aug 19, 2009, at 2:25 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-19 at 00:08 -0500, Kumar Gala wrote:
>> Support for TLB reservation (or TLB Write Conditional) and Paired MAS
>> registers are optional for a processor implementation so we handle
>> them via MMU feature sections.
>>
>> We currently only used paired MAS registers to access the full RPN
>> + perm
>> bits that are kept in MAS7||MAS3. We assume that if an
>> implementation has
>> hardware page table at this time it also implements in TLB
>> reservations.
>
> You also need to be careful with this code:
>
> virt_page_table_tlb_miss_done:
>
> /* We have overriden MAS2:EPN but currently our primary TLB miss
> * handler will always restore it so that should not be an issue,
> * if we ever optimize the primary handler to not write MAS2 on
> * some cases, we'll have to restore MAS2:EPN here based on the
> * original fault's DEAR. If we do that we have to modify the
> * ITLB miss handler to also store SRR0 in the exception frame
> * as DEAR.
> *
> * However, one nasty thing we did is we cleared the reservation
> * (well, potentially we did). We do a trick here thus if we
> * are not a level 0 exception (we interrupted the TLB miss) we
> * offset the return address by -4 in order to replay the tlbsrx
> * instruction there
> */
> subf r10,r13,r12
> cmpldi cr0,r10,PACA_EXTLB+EX_TLB_SIZE
> bne- 1f
> ld r11,PACA_EXTLB+EX_TLB_SIZE+EX_TLB_SRR0(r13)
> addi r10,r11,-4
> std r10,PACA_EXTLB+EX_TLB_SIZE+EX_TLB_SRR0(r13)
>
> You may want to make the 3 last lines conditional on having tlbsrx.
The whole thing only ever gets called if we had tlbsrx. so is there
any utility in making a part of conditional on tlbsrx?
> Right now, in the no-tlbsrx. case, what happens is that it will go
> back
> to the previous instruction, an or, which hopefully should be harmless
> -but- this code is nasty enough you really don't want to take that
> sort of chances.
>
> Feel free to add a fat comment next to the ld in the tlbsrx case
> itself
> explaining why those two instructions must be kept together and any
> change here must be reflected in the second level handler.
>
> Cheers,
> Ben.
>
More information about the Linuxppc-dev
mailing list