> -----Original Message----- > From: Michael Neuling [mailto:mi...@neuling.org] > Sent: Tuesday, February 12, 2013 9:46 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: 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 > > > > > bounces+Of 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. > > Yes, SRR1 == the MSR of the user process, not the current MSR. > > > Also on 32bit it looks like that R9 is assumed to have SRR1. > > Yep that too. > > So any idea how it's suppose to work or is it broken?
To me this looks wrong. And this seems to works because the thread->reg->msr is not actually used to write SRR1 (and eventually the thread MSR) when doing rfi to enter guest. Infact Guest(shadow_msr) MSR is used as SRR1 and which will have proper MSR (including FP set). But Yes, Scott is right person to comment, So let us wait for him comment. Thanks -Bharat _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
