BOOKE KVM calling load_up_fpu from C?

Bhushan Bharat-R65777 R65777 at freescale.com
Wed Feb 13 12:26:37 EST 2013



> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, February 13, 2013 6:53 AM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; Michael Neuling; linuxppc-dev at lists.ozlabs.org
> 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;
> > linuxppc-dev at lists.ozlabs.org
> > > 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



More information about the Linuxppc-dev mailing list