From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: fpu_taskswitch adjustment proposal Date: Mon, 18 Jun 2012 23:35:43 +0100 Message-ID: References: <20120618182450.GF24750@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120618182450.GF24750@phenom.dumpdata.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: Konrad Rzeszutek Wilk , Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 18/06/2012 19:24, "Konrad Rzeszutek Wilk" 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 > > Hm, the clts() paravirt could take advantage of the per-cpu cr0 to > figure out whether it truly needs to do anything. Exactly. >>> 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. >> >> 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? > > Would this require an extra pvops call from the #NM handler? Or we wrap the #NM handler (somehow?) and clear the per-cpu cr0.ts software flag before calling into the generic #NM handler. -- Keir