[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] fpu_taskswitch adjustment proposal


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxx>
  • Date: Mon, 18 Jun 2012 13:12:56 +0100
  • Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 18 Jun 2012 12:13:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac1NS7GIhaFcexrne0CyMjD4CkPDqA==
  • Thread-topic: [Xen-devel] fpu_taskswitch adjustment proposal

On 18/06/2012 08:32, "Jan Beulich" <JBeulich@xxxxxxxx> 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?




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.