Re: kvm BookE and SPRGs

[Hollis Blanchard <hollisb@us.ibm.com>]

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