[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 14:59:15 +0100
  • Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 18 Jun 2012 13:59:52 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac1NWou2yJlDpUZuz0qUu8ZOhgNVKg==
  • Thread-topic: [Xen-devel] fpu_taskswitch adjustment proposal

On 18/06/2012 13:45, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

>> 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?
> 
> The #NM handler part wouldn't afaict. Everything else indeed
> ought to be restricted to the functions backing paravirt.h's clts()
> and write_cr0().

Yes, the #NM handler might need extra treatment. Perhaps we could install
our own #NM wrapper around the kernel's generic handler, which first clears
the saved CR0.TS flag. Then on clts() in the generic handler, our paravirt
clts() would see the flag is already clear and do no hypercall.

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