> -----Original Message----- > From: kvm-ppc-owner@xxxxxxxxxxxxxxx > [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] On Behalf Of Alexander Graf > Sent: Friday, July 10, 2009 4:43 PM > To: Benjamin Herrenschmidt > Cc: kvm-ppc@xxxxxxxxxxxxxxx; Hollis Blanchard; Avi Kivity > Subject: Re: kvm BookE and SPRGs > > 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? > Sounds reasonable. There are some old patchset which implemented the binary patch as Ben described. http://marc.info/?l=kvm-ppc&m=122154653905212&w=2 http://marc.info/?l=kvm-ppc&m=122154657905306&w=2 -- 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
