Hi Ben,
On 10.07.2009, at 10:10, 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 ?
IMHO paravirt stuff can be really useful, but should stay in the
guest. I don't really like the idea of adding binary patching of
guests in the hypervisor more than for dcbz where I didn't see another
way to do it.
Linux does provide pv_ops for such purposes, or maybe you could use
the magic kernel patches itself hacks that exist in the power port
today already.
So then newer guests would be fast, older guests would be slow. Sounds
like a good tradeoff to me :-).
Maybe we could also do the hacks in the hypervisor, but #ifdef them
out by default. I always get stomachaches from patching guests by
default ;-).
[...]
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).
That seems to be guest responsibility, no?
--
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
