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

Re: [Xen-devel] [PATCH] x86/fpu: CR0.TS should be set before trap into PV guest's #NM exception handle


  • To: xen-devel@xxxxxxxxxxxxx
  • From: Sarah Newman <srn@xxxxxxxxx>
  • Date: Wed, 27 Nov 2013 15:35:21 -0800
  • Cc: "Crawford, Luke" <lsc@xxxxxxxxx>
  • Delivery-date: Wed, 27 Nov 2013 23:35:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

> Note the comment close to the beginning - the fact that CR0.TS
> is clear at exception handler entry is actually part of the PV ABI,
> i.e. by altering hypervisor behavior here you break all forward
> ported kernels.
> 
> Nevertheless I agree that there is an issue, but this needs to be
> fixed on the Linux side (hence adding the Linux maintainers to Cc);
> this issue was introduced way back in 2.6.26 (before that there
> was no allocation on that path). It's not clear though whether
> using GFP_ATOMIC for the allocation would be preferable over
> stts() before calling the allocation function (and clts() if it
> succeeded), or whether perhaps to defer the stts() until we
> actually know the task is being switched out. It's going to be an
> ugly, Xen-specific hack in any event.
> 
> Jan

This is a serious bug.  Unfortunately not all of us have the option of updating 
our guests if/when
such a fix is made to Linux.

How about a per domU + xen command line configuration option to implement Zhu's 
changes that is
disabled by default?  I'm willing to try to implement it.

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