> -----Original Message----- > From: Michael Neuling [mailto:mi...@neuling.org] > Sent: Tuesday, February 12, 2013 9:16 AM > To: Bhushan Bharat-R65777 > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org > Subject: Re: BOOKE KVM calling load_up_fpu from C? > > Bhushan Bharat-R65777 <r65...@freescale.com> wrote: > > > > > > > > -----Original Message----- > > > From: Linuxppc-dev [mailto:linuxppc-dev- > > > bounces+bharat.bhushan=freescale....@lists.ozlabs.org] On Behalf Of > > > bounces+Michael > > > Neuling > > > Sent: Tuesday, February 12, 2013 8:59 AM > > > To: Wood Scott-B07421 > > > Cc: linuxppc-dev@lists.ozlabs.org > > > Subject: BOOKE KVM calling load_up_fpu from C? > > > > > > Scott, > > > > > > I was looking at changing how load_up_fpu works and I found this in > > > arch/powerpc/kvm/booke.h: > > > > > > static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu) { > > > #ifdef CONFIG_PPC_FPU > > > if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) { > > > load_up_fpu(); > > > current->thread.regs->msr |= MSR_FP; > > > } > > > #endif > > > } > > > > > > I'm wondering how this is suppose to work since load_up_fpu is > > > suppose to have MSR in R12? > > > > Is not the load_up_fpu() does mfmsr: > > > > _GLOBAL(load_up_fpu) > > mfmsr r5 > > ori r5,r5,MSR_FP > > #ifdef CONFIG_VSX > > BEGIN_FTR_SECTION > > oris r5,r5,MSR_VSX@h > > END_FTR_SECTION_IFSET(CPU_FTR_VSX) > > #endif > > SYNC > > MTMSRD(r5) /* enable use of fpu now */ > > isync > > <snip> > > Look further down... > > #ifdef CONFIG_PPC32 > mfspr r5,SPRN_SPRG_THREAD /* current task's THREAD (phys) > */ > lwz r4,THREAD_FPEXC_MODE(r5) > ori r9,r9,MSR_FP /* enable FP for current */ > or r9,r9,r4 > #else > ld r4,PACACURRENT(r13) > addi r5,r4,THREAD /* Get THREAD */ > lwz r4,THREAD_FPEXC_MODE(r5) > ori r12,r12,MSR_FP > or r12,r12,r4 > std r12,_MSR(r1) > #endif > > R12 is loaded with SRR1 in the exception prolog before load_up_fpu is called.
Yes it is SRR1 not MSR. Also on 32bit it looks like that R9 is assumed to have SRR1. -Bharat > It's the MSR of the user process, not the current MSR. > > Mikey _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
