On Tue, 2011-08-30 at 09:15 -0500, Stuart Yoder wrote: > Also, note-- we (Freescale) do have a patchset coming soon for the e500mc > which is a 2.06 embedded 32-bit CPU with category E.HV. We've had this > running for a while and are close to finishing some cleanup before posting > upstream. We are are also starting to look at 64-bit support for our e5500 > CPU we should be a delta on top of the e500mc support. > > Just want to make you aware of some current work that may overlap your > A2 KVM support...
The main difference will be the MMU version (FSL is MAV1, A2 is MAV2), and overall TLB structure. The rest should be mostly identical :-) I suspect the TLB virtualization code will be quite different, but it's really going to depend what approach Kun decides to use. You can probably start with doing simple SW load, but performance will suck. Other options that I've been thinking about to try to exploit indirect TLB entries (HW load) in no specific order: - Use the LRAT. (How ? It's small, meant for huge translations ... maybe on top of some large part support & demand fault it using a really short asm code path ? Some kind of linear array of 16M translations like we do on power7 KVM ?). Using the LRAT means that you enable the guest direct use of indirect TLB. - Shadow page tables. Paravirtualize (or emulate) insertion of indirect entries and have the HV maintain pre-translated shadows. That means all page faults must go to KVM though, in order to handle protection changes, and you need some reverse mapping to be able to deal with invalidations, unless you "trick" with paravirt rather than full virt, such as notifying KVM when you populate a PTE. - Like the above but additionally have KVM walk the guest page tables directly and only forward to the guest actual PTE faults. Might require some kind of hcall to tell kvm about the root of the tree (roots actually) on context switch etc... might not be worth it but may also save you overhead. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
