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

Re: [Xen-devel] fpu_taskswitch adjustment proposal


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

On 18/06/2012 19:24, "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx> 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



_______________________________________________
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®.