This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH] FPU LWP 6/8: create lazy and non-lazy FPU re

To: "Wei Huang" <wei.huang2@xxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] FPU LWP 6/8: create lazy and non-lazy FPU restore functions
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 06 May 2011 08:49:18 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, KeirFraser <keir@xxxxxxx>
Delivery-date: Fri, 06 May 2011 00:50:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DC31973.8040009@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4DC062ED.3070802@xxxxxxx> <4DC117D6020000780003F9CB@xxxxxxxxxxxxxxxxxx> <4DC17FF3.5080706@xxxxxxx> <4DC26A46020000780003FC3E@xxxxxxxxxxxxxxxxxx> <4DC31973.8040009@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 05.05.11 at 23:41, Wei Huang <wei.huang2@xxxxxxx> wrote:
> Hi Jan,
> If we want to make LWP restore optional in vcpu_restore_fpu_eager(), we 
> have to change vcpu_save_fpu() as well. Otherwise, the extended state 
> will become inconsistent for non-LWP VCPUs (because save and restore is 
> asymmetric). There are two approaches:
> 1. In vcpu_save_fpu(), clean physical CPU's extended state for VCPU 
> which is being scheduled in. This prevents messy states from causing 
> problems. The disadvantage is the cleaning cost, which would out-weight 
> the benefits.

Cleaning cost? Wasn't it that one can express to default-initialize
fields during xrstor (which, if indeed expensive, you'd want to trigger
only if you know the physical CPU's state is dirty, i.e. in this case
requiring a per-CPU variable that gets evaluated and updated on
context restore).

> 2. Add a new variable in VCPU to track whether nonlazy state is dirty. I 
> think this is better. See the attached file.
> Let me know if it is what you want. After that, I will re-spin the patches.

Yes, this looks like what I meant. Two suggestions: The new field's
name (nonlazy_xstate_dirty) would perhaps better be something
like nonlazy_xstate_used, so that name and use are in sync. And
the check in vcpu_restore_fpu_eager() probably doesn't need to
re-evaluate xsave_enabled(v), since the flag can't get set without
this (if you absolutely want to, put in an ASSERT() to this effect).


Xen-devel mailing list