> -----Original Message----- > From: Hollis Blanchard [mailto:holl...@us.ibm.com] > Sent: Wednesday, April 29, 2009 3:34 AM > To: Liu Yu-B13201 > Cc: kvm-ppc@vger.kernel.org; rkulk...@force10networks.com > Subject: Re: [PATCH 1/3] kvm/e500: Do not keep shadow tlb array > > On Mon, 2009-04-27 at 14:58 +0800, Liu Yu wrote: > > Shadow tlb array costs a lot memory > > and incurs potential coherence problem. > > > > Remove it and we now translate to shadow mappings directly > > from guest TLB entries. > > > > Signed-off-by: Liu Yu <yu....@freescale.com> > > Well, funny story... pretty much as soon as we removed the > shadow TLB on > 440, we put it back. But we use it differently now. Our experience on > 440 was that it was a performance win to *also* keep a shadow > TLB array, > but use that *only* in the vcpu_put/vcpu_load() path instead > of tlbia(). > In other words, instead of just clearing all that guest TLB state you > worked so hard to build up, preserve it across host context switches. > > We don't use that array for anything other than host context switches. > For normal exits (handled in kernel or handled in qemu) we take a less > precise "shadowy" approach, where host and guest TLB entries > can compete > without KVM's knowledge, and we indiscriminately invalidate them. > > (Yes, http://www.linux-kvm.org/page/PowerPC_Book_E_MMU is no longer > completely accurate.) > > I'm not sure what the coherence problems are that you allude > to, but we > never did SMP host support for 440.
It's not a SMP coherence problem. But that after we apply shadow id trick, the shadow tlb entry may be expired due to the change of id mapping. As we always update PID0, PID1 to the latest shadow id, write expired shadow entry back is useless and may incur other problem. Moreover after applying shadow id trick, there is no tlbia() in the vcpu_load()/vcpu_put(). So I think it doesn't affect the performance of e500. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
