From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] VMX: XSA-60 workaround Date: Wed, 14 Aug 2013 11:12:07 +0100 Message-ID: <520B57F7.5000307@citrix.com> References: <520A7CA202000078000EB9DB@nat28.tlf.novell.com> <520A636C.9030903@citrix.com> <520B63C702000078000EBC78@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 1V9Y3s-00014J-Uc for xen-devel@lists.xenproject.org; Wed, 14 Aug 2013 10:12:17 +0000 In-Reply-To: <520B63C702000078000EBC78@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 , Keir Fraser , Eddie Dong , Jun Nakajima List-Id: xen-devel@lists.xenproject.org On 14/08/13 10:02, Jan Beulich wrote: >>>> On 13.08.13 at 18:48, Andrew Cooper wrote: >> On 13/08/13 17:36, Jan Beulich wrote: >>> Considering that there's still no real progress towards a resolution >>> for XSA-60, I'd like to propose turning off the probelamtic code by >>> default, allowing it to be turned back on via command line option. >>> >>> Signed-off-by: Jan Beulich >> In principle, ok, but can I suggest that this initially goes in with a >> per domain warn once, (and perhaps gdprintk afterwards), so guests which >> actually try to use this can at least be identified if they suddenly >> start behaving weirdly? > No, that's pointless: Various (if not all) Linux versions set CR0.CD > in the course of fiddling with th MTRRs, i.e. we'd issue this warning > for most if not all HVM Linux guests that also have some PCI device > assigned, even though in the vast majority of cases this would be > benign to them. The one case where I'm told that broken code is > needed for guest stability is when a graphics device gets assigned > to it (proof of that is yet to be seen though), yet at the point > where the warning would need to get issued we shouldn't go as > far as looking for specific device types (even more so when there > might be other device classes where the cache disabling would > also be needed). > > Jan > Hmm. At the very least there should be a boot time message indicating whether playing with the CD bit is enabled or not. What can't happen is that we silently change the behaviour of something like this, which does have suspected impact in certain usecases. ~Andrew