If the final implementation is going to be as per this thread: http://lists.linaro.org/pipermail/boot-architecture/2011-August/000058.html then this shouldn't actually be an issue right? On Wed, Feb 1, 2012 at 8:40 AM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > On 01/02/12 12:20, Peter Maydell wrote: >> On 1 February 2012 12:11, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >>> The obvious fix would be to test for the virt extensions in ID_PFR1 >>> before enabling KVM, and mask out the virt extensions from the same >>> register in the guest by trapping CP15-c0. But c0 is used by cache >>> maintenance operations, and trapping would lead to unacceptable >>> performance degradation. >> >> You can just set HCR.TID3 to get hyp traps on only the feature >> ID registers, right? (traps access to only ID_PFR0, ID_PFR1, ID_DFR0, >> ID_AFR0, ID_MMFR0, ID_MMFR1, ID_MMFR2, ID_MMFR3, ID_ISAR0, ID_ISAR1, >> ID_ISAR2, ID_ISAR3, ID_ISAR4, ID_ISAR5, MVFR0, and MVFR1, none >> of which should be on performance-critical paths I hope.) > > Good catch. It looks much better, except that ID_MMFR3 is used in > cpu_v7_set_pte_ext(), which is called each time you map a page. Ouch. > > I'm not even sure we can the cache ID_MMFR3 in the kernel (multi-cluster > systems may have different features). > > M. > -- > Jazz is not dead. It just smells funny... > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html