From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: fpu_taskswitch adjustment proposal Date: Mon, 18 Jun 2012 13:12:56 +0100 Message-ID: References: <4FDEF595020000780008A5B7@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FDEF595020000780008A5B7@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Konrad Rzeszutek Wilk , xen-devel List-Id: xen-devel@lists.xenproject.org On 18/06/2012 08:32, "Jan Beulich" wrote: >> It should be possible for the guest kernel to track its CR0.TS setting >> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly >> cleared on #NM. > > Sure, but selling this to the Linux maintainers I would expect to be > harder than fitting the Xen side of things into the current save- > and-restore model the native xor code uses. It would only be strait > forward to implement on the legacy, forward ported trees. Wouldn't it be hidden entirely behind pv_ops hooks and within Xen-specific SSE save/restore code? I suppose you'd need to statically allocate the per-cpu space for tracking the CR0.TS state... But overall it seems it will be of little/no concern to other kernel maintainers? -- Keir > However, with the #NM handler in pv-ops apparently not > leveraging the fact that CR0.TS is already cleared for it on entry, > maybe this could indeed be introduced together. Konrad?