From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sarah Newman Subject: Re: [PATCH] x86/fpu: CR0.TS should be set before trap into PV guest's #NM exception handle Date: Wed, 27 Nov 2013 15:35:21 -0800 Message-ID: <529681B9.4010503@prgmr.com> References: <52967C45.3030506@prgmr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52967C45.3030506@prgmr.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: xen-devel@lists.xen.org Cc: "Crawford, Luke" List-Id: xen-devel@lists.xenproject.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.