On 1 February 2012 13:40, 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). We only look at the coherent-walk bits there, right? We can just cache a single "does any core require clean-to-PoU after translation table update?" [ie "does any core have 0 in this field?"] flag, I guess. The chances that you actually have a cluster with different cores differing here seem quite low[*], and if we do encounter one then cleaning the dcache line even on the cores that don't need it would be a safe if slightly less than optimal approach... [*] particularly since every multicore Cortex A-class processor supports coherent walk... -- PMM -- 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
