On Sat, 2008-08-30 at 11:15 +0800, Liu Yu wrote: > > > Unlike 44x use TID=0 map userspace and TID=1 map kernel space, > > > I plan to use host TLB1 to map kernel, and host TLB0 to map > > userspace. > > > This category can make it convient to handle privilege > > switch: that is > > > before enterring guest just need tlbivax TLB1. > > > Userspace tlb enties with differnet TID can exist in host > > TLB0 till host > > > kvm process switch or guest meet explicit tlbiax command. > > > > > > I just have this idea and have not thought all the detail through. > > > What do you think of it? > > > > You might run into problems if you ever get large guest userspace > > mappings. I know hugetlbfs doesn't exist for e500 Linux right now, but > > it could in the future, and plus there are other kernels to consider. > > Can you give me more details? > I'm not sure how hugetlbfs could be in the future, but TLB0 has a fixed > mapping size 4KB. You can't assume that TLB1 does not contain user mappings, because that's not true with hugetlbfs. Of course, hugetlbfs doesn't (yet?) exist for e500, so the assumption is valid until that happens. However, we *really* need large host page mappings to make KVM fast. Right now we have to split guest large pages (covering the kernel) into lots of 4K mappings, which means our TLB miss rate is *much* higher than if we could use hugetlbfs on the host. In that case, we could use hugetlbfs large user pages to back the guest kernel mappings. > > > > booke_fsl_interrupts.S looks like a lot of code copied and > > > > pasted, with > > > > the obvious exception of the TLB handlers. Can't we work out > > > > some better > > > > way to share the rest? > > > > > > That would be great. > > > I just considered it step-by-step, and I am not very > > familiar with gnu > > > assemble macro, define things, > > > and I nocited head_fsl_booke.S and head_44x.S... > > > > > > I will think about it. > > > > OK, so there are two basic differences in booke_interrupts.S, and > > they're both in the common "lightweight exit" path: the additional PID > > register switching and the modifications to the TLB save/restore. > > > > The PID stuff should be easy enough to hide: just create a > > "KVMPPC_SAVE_PID" macro. > > Do we need a new header file to define this? Yup, we'd need something like e500_interrupts.h and 440_interrupts.h, and these would only be included from booke_interrupts.S. > > For now we can probably do the same with the TLB manipulations. > > How do you think the way I define struct tlb_array and tlbe? > If you think it's fine, I think 44x can adopt it. I've been meaning to rename "struct tlbe" for a long time. It should really be called "kvmppc_440_tlbe" or something. As for the dynamic allocation of the TLB arrays, instead of building them into struct kvm_vcpu_arch, I think that probably makes sense. A little more annoying to manage, but makes sense. -- Hollis Blanchard IBM Linux Technology Center -- 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
