Re: [Xen-devel] [PATCH for-4.11 v2] x86/EFI: further correct FPU state handling around runtime calls

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 25 June 2018 13:49
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-devel <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>; Juergen Gross <jgross@xxxxxxxx>
> Subject: RE: [PATCH for-4.11 v2] x86/EFI: further correct FPU state handling
> around runtime calls
> 
> >>> On 25.06.18 at 14:24, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 25 June 2018 13:18
> >> --- a/xen/arch/x86/i387.c
> >> +++ b/xen/arch/x86/i387.c
> >> @@ -206,11 +206,11 @@ static inline void fpu_fxsave(struct vcp
> >>  /*       VCPU FPU Functions    */
> >>  /*******************************/
> >>  /* Restore FPU state whenever VCPU is schduled in. */
> >> -void vcpu_restore_fpu_eager(struct vcpu *v)
> >> +void vcpu_restore_fpu_nonlazy(struct vcpu *v, bool need_stts)
> >>  {
> >>      /* Restore nonlazy extended state (i.e. parts not tracked by CR0.TS). 
> >> */
> >>      if ( !v->arch.fully_eager_fpu && !v->arch.nonlazy_xstate_used )
> >> -        return;
> >> +        goto maybe_stts;
> >
> > It's really just an 'out' label (AFAICT, since need_stts needs to be true
> > for there to be any other semantic) so how about just calling it that rather
> > than 'maybe_stts'?

Ok, I don't have a strong object the maybe_stts name so...

Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

> 
> To be honest, I like "out" less, as being too generic a name. Nor am I
> convinced that, going forward (and leaving aside the fact that we may
> decide to drop lazy mode altogether), all code paths need to reach there.
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel