> -----Original Message----- > From: Wood Scott-B07421 > Sent: Wednesday, February 13, 2013 6:53 AM > To: Bhushan Bharat-R65777 > Cc: Wood Scott-B07421; Michael Neuling; [email protected] > Subject: Re: BOOKE KVM calling load_up_fpu from C? > > On 02/12/2013 07:18:14 PM, Bhushan Bharat-R65777 wrote: > > > > > > > -----Original Message----- > > > From: Wood Scott-B07421 > > > Sent: Wednesday, February 13, 2013 12:03 AM > > > To: Bhushan Bharat-R65777 > > > Cc: Michael Neuling; Wood Scott-B07421; > > [email protected] > > > Subject: Re: BOOKE KVM calling load_up_fpu from C? > > > > > > On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote: > > > > 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. > > > > > > I don't think it's actually a problem on 32-bit, since r9 is > > modified but never > > > actually used for anything. > > > > Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and > > then r9 is written back in srr1 ? > > What epilog? We're talking about the case where it's called from C code > > When it's called from an exception handler, then r9 is used, but in that case > it's also initialized before calling load_up_fpu, by the prolog.
Agree. Was just confirming the exception handler case. > > > > On 64-bit, though, there's a store to the caller's stack frame > > > (yuck) which the kvm/booke.h caller is not prepared for. > > > > So if caller is using r12 then it can lead to come corruption, right ? > > No, r12 is a volatile register in the ABI, as is r9. The issue is that the > stack can be corrupted. Ok, Thanks -Bharat > > -Scott _______________________________________________ Linuxppc-dev mailing list [email protected] https://lists.ozlabs.org/listinfo/linuxppc-dev
