> I've been considering if keeping the shadow TLB data > structure around is > the right approach. To begin with, Linux does not keep an analogous > structure, and it's basically the same problem: when resuming > the guest > after a context switch, the TLB will be mostly empty of guest entries, > and suffer a high TLB miss rate until it can fault more back in. If we remove the shadow TLB, can we improve this? In kvm booke implementation, after a host context switch, I think the TLB should be invalidated unless the core won't switch to another vcpu. > > The shadow TLB allows us to skip the repopulation phase, but at the > expense of some memory and some overhead on every exit. Also, it's > difficult or impossible to implement a shadow TLB on cores where > software cannot address TLB entries by index (i.e. the hardware > automatically selects the index). Shadow TLB also avoid recalculation, the value of shadow tlb entry can be directly written into hardware. And get and put page can be save as well. btw, why do we need to update TLB on every exit, why can't we just update it on miss? > > If we did remove the shadow TLB, I think we'd suffer even more TLB > misses, so we'd need to really optimize our TLB miss handler. Could you give more pros. about removing the shadow TLB? To make TLB handler can fit more processors? > (Arguably > we should already be doing that anyways.) Linux's TLB miss > handler walks > the Linux page tables entirely in assembly, which also > removes the need > to save/restore the full C ABI set of GPRs. Linux's TLB miss handler handles page table which is simple to address (the input argument is entry's address), while our handler handles tlb entry table which may be complex to address (the input argument is entry's tag). > > Logically speaking, our TLB miss handler must do the following: > 1. walk guest TLB(s) to find a matching entry If we implement large guest TLB in the future, we might need to involve advanced data structure such as rb-tree. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
