From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: XSA-60 - how to get back to a sane state Date: Tue, 3 Dec 2013 02:21:36 +0000 Message-ID: <529D4030.6040501@citrix.com> References: <529CA7250200007800108CB8@nat28.tlf.novell.com> <529CE2D5.7030805@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 1VnfcI-0002GW-DS for xen-devel@lists.xenproject.org; Tue, 03 Dec 2013 02:21:38 +0000 In-Reply-To: <529CE2D5.7030805@eu.citrix.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: George Dunlap , Jan Beulich , xen-devel Cc: Jinsong Liu , Keir Fraser , Zhenzhong Duan , Donald D Dugger , Jun Nakajima List-Id: xen-devel@lists.xenproject.org On 02/12/2013 19:43, George Dunlap wrote: > On 12/02/2013 02:28 PM, Jan Beulich wrote: >> All, >> >> Jinsong's patches having been in for nearly a month now, but not >> being in a shape that would make releasing in 4.4 or backporting to >> the older trees desirable, we need to come to a conclusion on >> which way to go. Currently it looks like we have three options, but >> of course I'll be happy to see other (better!) ones proposed. >> >> 1) Stay with what we have. >> >> 2) Revert 86d60e85 ("VMX: flush cache when vmentry back to UC >> guest") in its entirety plus, perhaps, the change 62652c00 ("VMX: >> fix cr0.cd handling") did to vmx_ctxt_switch_to(). >> >> 3) Apply the attached patch that Andrew and I have been putting >> together, with the caveat that it's still incomplete (see below). >> >> The latter two are based on the observation that the amount of >> cache flushing we do with what is in the master tree right now is >> more than what we did prior to that patch series but still >> insufficient. Hence the revert would get us back to the earlier >> state (and obviously eliminate the performance problems that >> were observed when doing too eager flushing), whereas >> applying the extra 5th patch would get us closer to a proper >> solution. > > What's missing is a description of the pros and cons of 1 and 2. Do > you have any links to threads describing the problem? > > -George > 1) has the basic XSA-60 fixes and some wbinvd()s, which are a significant performance issue and insufficient to completely fix the problem at hand. As a result, 1) is the worst possible option to stay with as far as Xen is concerned (irrespective of the upcoming 4.4 release). 2) will revert us back to the basic XSA-60 with none of the wbinvd()s, which fixes the security issue and is no worse than before in terms of a correctness-in-the-case-of-uncachable-hvm-domains point of view. 3) as-is is still insufficient to fix the problem in 1), and would currently result in a further performance regression. FWIW, my vote is for option 2) which will ease the current performance regression, in favor of allowing us time to come up with a proper solution to the pre-existing problem of Xen and Qemu mappings of a UC domain's memory. ~Andrew