Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753696Ab2FYIaW (ORCPT ); Mon, 25 Jun 2012 04:30:22 -0400 Received: from mga02.intel.com ([134.134.136.20]:29888 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751539Ab2FYIaU convert rfc822-to-8bit (ORCPT ); Mon, 25 Jun 2012 04:30:20 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="162182415" From: "Liu, Jinsong" To: Jan Beulich CC: "Raj, Ashok" , "Dugger, Donald D" , "Shan, Haitao" , "Nakajima, Jun" , "Li, Susie" , "Luck, Tony" , "Auld, Will" , "Zhang, Xiantao" , "Jiang, Yunhong" , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Keir Fraser Subject: RE: [vMCE design RFC] Xen vMCE design Thread-Topic: [vMCE design RFC] Xen vMCE design Thread-Index: AQHNUIitexbUH0BVTLGVMLMLWAtaJ5cKtlBA Date: Mon, 25 Jun 2012 08:30:17 +0000 Message-ID: References: <4FE362C0020000780008B2CD@nat28.tlf.novell.com> <4FE475BE020000780008B624@nat28.tlf.novell.com> <4FE4A636020000780008B756@nat28.tlf.novell.com> In-Reply-To: <4FE4A636020000780008B756@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2250 Lines: 48 Jan Beulich wrote: >>>> On 22.06.12 at 15:46, "Liu, Jinsong" wrote: >> Jan Beulich wrote: >>> One other concern that occurred to me after long having sent >>> the original response: Your proposal aims at a fixed, >>> unmodifiable vMCE interface. How is that going to be forward >>> compatible? I.e. consider you had made that proposal before >>> the SRAO/SRAR changes went in - would the same interface (with >>> the same set of capability bits set/clear) still be suitable? >> >> Yes, since it's pure s/w emulated interface. At the case when SRAO >> or SRAR not supported by h/w platform, it's still OK, since under >> such case hypervisor don't need deliver SRAO or SRAR to guest at >> all. The emulated vMCE interface just tell the guest that it runs at >> a virtual platform with those well-defined capabilities. > > I probably didn't express well enough what I want you to check: > Consider you had done the current re-design work without > SRAO/SRAR in mind (e.g. a couple of years ago). Would the > end result have been the same? Namely, would the bits you > nominate to be set/clear in MCG_CAP be the same? > >>> I think that we minimally need to retain the MCG_CAP register >>> as being of potentially variable content (and hence needing >>> saving/restoring on migration). To support this in a forward >>> compatible manner, we may have to have a way to tell the >>> hypervisor e.g. via command line option which extra MSRs >>> have to be treated read-as-zero/writes-ignored upon guest >>> accesses. >> >> Seems unnecessary, reason as above. > > So going forward you see no possibility of additions to the > interface that might warrant allowing more bits to be set in > MCG_CAP than you define to be set here? That really looks > unrealistic to me. > > Jan Sorry for misunderstanding your meaning in my last email, please ignore it. I agree that MCG_CAP should be save/restore when migration, considering in the future some CAP bit may be added. Thanks, Jinsong-- 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/