On Fri, 2009-07-10 at 16:31 +1000, Benjamin Herrenschmidt wrote: > > I was roaming through kernel usage of SPRGs and noticed a small detail > in kvmppc for BookE ... any reason why in OP_31_XOP_MTSPR, you > open coded the emulation of SPRG0..3, but 4...7 are handled > in kvmppc_core_emulate_mtspr() ? > > It occurs to me that in fact for both MTSPR and MFSPR, the code should > be moved into kvmppc_core_emulate_mtspr() and > kvmppc_core_emulate_mfspr() for consistency. > > Also, from looking at the FSL BookE code, it seems that there is such a > thing as SPRG9 (and so I suppose there must be an SPRG8 somewhere too), > shouldn't we handle it too ? BTW. That leads me to another question (CC'ing Avi there too), which is what is the policy vs. para-virtualization ? IE. Are we ok with adding paravirt tricks to speed things up ? A prime example I have in mind that could possibly help a lot here is to have a shared page mapped at -4K (at the top of the address space) when the guest is in supervisor mode only that hosts part of the current VCPU supervisor register state. That way, we could, either using our existing "alternate" instruction patching mechanism, or maybe lazily patching them as we trap on them, replace instructions such as mtsprg and mfsprg with la/sta (load absolute/store absolute) from/to this page (absolute addresses on ppc are 16 bits signed so can reach either the top of the bottom of the address space). We could also access the guest MSR read only that way, the guest SRR0 and SRR1, and a few more things. I also have ideas to do soft irq disabling that way as well which would eventually remove most if not all the spurrious emulation traps in the exception entry/exit of the guest kernel. (Note: this is paravirt even if we patch instructions on traps, in part because if we use that instead of SPRGs, then the values will not be reflected in the user readable SPRG aliases, so the guest kernel needs to be aware of that, typically, the current BookE code -does- use the user readable variants of SPRG4..7 so we must be careful here). The cost of course is an additional TLB entry for mapping that -4K page (but only when running guest kernel code). (Note: this technique would apply to KVM ppc64 from Alex as well) Cheers, Ben. -- 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
