From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luke S. Crawford" Subject: Re: [PATCH] x86/fpu: CR0.TS should be set before trap into PV guest's #NM exception handle Date: Mon, 02 Dec 2013 01:58:16 -0800 Message-ID: <529C59B8.6060201@prgmr.com> References: <52967C45.3030506@prgmr.com> <529681B9.4010503@prgmr.com> <52986F90020000780010814A@nat28.tlf.novell.com> <52992E4A.3050109@prgmr.com> <529C54170200007800108879@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VnQGh-0001h2-JV for xen-devel@lists.xenproject.org; Mon, 02 Dec 2013 09:58:19 +0000 In-Reply-To: <529C54170200007800108879@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 , Sarah Newman Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 12/02/2013 12:34 AM, Jan Beulich wrote: > The thing is that a guest admin may not have access to the VM's > config file, i.e. a satisfactory solution ought to involve only guest > side actions. A service provider who allows customers to run their own kernel would see it the other way around. That is the situation I find myself in. I don't have access to my guest's config files. Something I can do as the manager of the dom0 to ameliorate the problem without requiting the customers to do anything, and without requiring me to break into the guest and figure out how to patch whatever random kernel they might be using would help me a lot.