Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762293Ab2FVPGV (ORCPT ); Fri, 22 Jun 2012 11:06:21 -0400 Received: from nat28.tlf.novell.com ([130.57.49.28]:50924 "EHLO nat28.tlf.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762265Ab2FVPGU convert rfc822-to-8bit (ORCPT ); Fri, 22 Jun 2012 11:06:20 -0400 Message-Id: <4FE4A636020000780008B756@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 22 Jun 2012 16:07:02 +0100 From: "Jan Beulich" To: "Jinsong Liu" Cc: "Ashok Raj" , "Donald D Dugger" , "Haitao Shan" , "Jun Nakajima" , "Susie Li" , "Tony Luck" , "Will Auld" , "Xiantao Zhang" , "Yunhong Jiang" , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "Keir Fraser" Subject: RE: [vMCE design RFC] Xen vMCE design References: <4FE362C0020000780008B2CD@nat28.tlf.novell.com> <4FE475BE020000780008B624@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: 1978 Lines: 43 >>> 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 -- 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/