On Fri, 2009-07-10 at 18:10 +1000, Benjamin Herrenschmidt wrote: > 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 ?
Yes, that's fine. We would rather not *require* paravirtualization though. > 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. ... > The cost of course is an additional TLB entry for mapping that -4K page > (but only when running guest kernel code). It was a net win when Christian implemented it last year. While the first access may miss in the TLB, these register accesses tend to come in bunches (i.e. the guest interrupt vectors). -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
