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: Fri, 29 Nov 2013 16:16:10 -0800 Message-ID: <52992E4A.3050109@prgmr.com> References: <52967C45.3030506@prgmr.com> <529681B9.4010503@prgmr.com> <52986F90020000780010814A@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VmYEM-0008Ur-9K for xen-devel@lists.xenproject.org; Sat, 30 Nov 2013 00:16:18 +0000 In-Reply-To: <52986F90020000780010814A@nat28.tlf.novell.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: Jan Beulich Cc: xen-devel , Luke Crawford List-Id: xen-devel@lists.xenproject.org On 11/29/2013 01:42 AM, Jan Beulich wrote: > I'm personally not eager to see something like this go in, most > importantly because I think bugs should be fixed where they > got introduced, not worked around elsewhere, and also > because I think that a generally available workaround would > lower the chances of the bug getting fixed properly. If the proper bug fix was released first would that help? > > Apart from that this workaround of yours would have very > ugly behavior: If a guest later got updated to a fixed kernel, > you'd have to alter its configuration along with booting into > the new kernel (i.e. a simple reboot of the VM won't do), or > else your new kernel would crash due to not clearing CR0.TS > before trying to restore FPU context. Assuming it predictably crashed, that would be easier to deal with than occasional silent memory corruption. I think something could be done with the on_reboot action, maybe a reload-restart?