Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758003Ab2F1JIU (ORCPT ); Thu, 28 Jun 2012 05:08:20 -0400 Received: from nat28.tlf.novell.com ([130.57.49.28]:43838 "EHLO nat28.tlf.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755229Ab2F1JIT convert rfc822-to-8bit (ORCPT ); Thu, 28 Jun 2012 05:08:19 -0400 Message-Id: <4FEC3B4A020000780008C673@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 28 Jun 2012 10:08:58 +0100 From: "Jan Beulich" To: "Jinsong Liu" , "Will Auld" Cc: "Ashok Raj" , "Donald D Dugger" , "Haitao Shan" , "Jun Nakajima" , "Susie Li" , "Tony Luck" , "Xiantao Zhang" , "Yunhong Jiang" , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "Keir Fraser" Subject: RE: [xen vMCE RFC V0.2] xen vMCE design References: <4FEB236C020000780008C392@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1917 Lines: 40 >>> On 28.06.12 at 10:54, "Liu, Jinsong" wrote: > Jan Beulich wrote: >> The 2-bank approach also needs to be brought in line with the >> current host derived value in MCG_CAP, especially if the code to >> implement this new model doesn't make it into 4.2 (which would >> generally save a larger value). > > Let me repeat in my word to avoid misunderstanding about your concern: > Your concern rooted from the history patch (c/s 24887, as attached) which > used to solve vMCE migration issue caused from bank number. I guess the patch > was not in xen4.1.x but would be in xen 4.2 release recently (right? and when > will xen 4.2 release?) 4.2 is in feature freeze right now, preparing for the release. > Per my understanding, you want us to make sure our new vMCE model compatible > w/ olde vMCE. For example if our patch in xen 4.3 release, you want to make > sure a guest migrate from xen 4.2 to 4.3 would not broken. Is this your > concern? Yes. If we can't get the save/restore records adjusted in time for 4.2, compatibility with 4.2 would be a requirement. If we manage to get the necessary adjustments done in time, and if they're not too intrusive (i.e. would be acceptable at this late stage of the development cycle), then the concern could be dropped from an upstream perspective due to the lack of support in 4.1 (and hence no backward compatibility issues). BUT this isn't as simple from a product usage point of view: As the save/restore code currently in -unstable was coded up to address a problem observed by SLE11 SP2 users, we already backported those patches. So compatibility will be a requirement in any case. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/