> -----Original Message----- > From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] > Sent: Wednesday, June 27, 2012 1:16 AM > To: Caraman Mihai Claudiu-B02008 > Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; qemu-...@nongnu.org; Anton Blanchard > Subject: Re: [RFC PATCH 13/17] PowerPC: booke64: Use SPRG0/3 scratch for > bolted TLB miss & crit int > > On Mon, 2012-06-25 at 15:26 +0300, Mihai Caraman wrote: > > Embedded.Hypervisor category defines GSPRG0..3 physical registers for > guests. > > Avoid SPRG4-7 usage as scratch in host exception handlers, otherwise > guest > > SPRG4-7 registers will be clobbered. > > For bolted TLB miss exception handlers, which is the version currently > > supported by KVM, use SPRN_SPRG_GEN_SCRATCH (aka SPRG0) instead of > > SPRN_SPRG_TLB_SCRATCH (aka SPRG6) and replace TLB with GEN PACA slots > to > > keep consitency. > > For critical exception handler use SPRG3 instead of SPRG7. > > Beware with SPRG3 usage. It's user space visible and we plan to use it > for other things (see Anton's patch to stick topology information in > there for use by the vdso). If you clobber it, you may want to restore > it later.
In booke3e case SPRG3 will not be clobbered by the guests which access GSPRG3, but by the host exception handler. This means that we will have to restore SPRG3 even in the absence of KVM. My proposal is to add a PACA slot for r13 and save it in the same way you did with r12 in TLB_MISS_PROLOG. Then we can restore SPRG3 right in the prolog thus also avoiding to deal with it in KVM. The EXCEPTION_PROLOG is a common define for GEN/DBG/CRIT/MC, we use addition defines to specialize just the CRIT case. > I think Anton's patch should put the "proper" value we want in the PACA > anyway since we also need to restore it on exit from KVM, so you can > still use it as scratch, just restore the value before going to C. I just saw last iteration of Anton's vsdo patch that matches your description. Cheers, -Mike _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
