On Wed, Oct 30, 2013 at 1:53 AM, Sebastian Macke <sebast...@macke.de> wrote: > On 29/10/2013 2:01 PM, Max Filippov wrote: >> >> On Tue, Oct 29, 2013 at 11:04 PM, Sebastian Macke <sebast...@macke.de> >> wrote: >>> >>> At the moment there are two TLBs. The OpenRISC TLB followed >>> by the QEMU's own TLB. >>> At the end of the TLB miss handler a tlb_flush of QEMUs TLB >>> is executed which is exactly what we want to avoid. >>> As long as there is no context switch we don't have to flush the TLB. >> >> So this flush was needed in order to clean QEMU TLB in case >> DTLB/ITLB translation was enabled/disabled, right? But since you >> already have mmu index for nommu operation, wouldn't it be easier >> to indicate mmu index correctly for data and code access and drop >> this flush? >> > > The mmu index is already set correctly and this patch removes the flush.
I'm not sure: cpu_mmu_index only checks SR_IME, not SR_DME. > 1. Problem > The problem is if there is a context switch. OpenRISC clears its own small > tlb page by page. But this does mean it flushes all pages in the big QEMU I think there shouldn't be any entries in QEMU TLB other than those in OpenRISC TLB, otherwise it would be possible to access unmapped virtual addresses without getting pagefaults. > TLB. This is the reason why l.rfe instruction clears the tlb which is the > instruction used to return to user mode > But according to the specification this is wrong. > > 2. Problem which is the case you mentioned. > Your are right, this is one solution and its written in the patchnotes as > point 1. > But this would not solve the problem No 1. I mentioned in this email. > > Confused? I am :) > > Easy: l.rfe is not supposed to clear the tlb. It can but it shouldn't. > With this patch I remove the flush and solve all problems by assuming a > global tlb flush if you invalidate the first entry of the small OpenRISC > TLB. -- Thanks. -- Max