Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754581Ab2FZLF2 (ORCPT ); Tue, 26 Jun 2012 07:05:28 -0400 Received: from mail-qa0-f46.google.com ([209.85.216.46]:46577 "EHLO mail-qa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752176Ab2FZLF0 (ORCPT ); Tue, 26 Jun 2012 07:05:26 -0400 MIME-Version: 1.0 In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com> References: <4FE362C0020000780008B2CD@nat28.tlf.novell.com> <4FE475BE020000780008B624@nat28.tlf.novell.com> <4FE4A636020000780008B756@nat28.tlf.novell.com> <3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com> Date: Tue, 26 Jun 2012 12:05:25 +0100 X-Google-Sender-Auth: 3prl5DUgWXzn1tm7cc0URBMNNSk Message-ID: Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design From: George Dunlap To: "Luck, Tony" Cc: Jan Beulich , "Liu, Jinsong" , "Jiang, Yunhong" , Keir Fraser , "Raj, Ashok" , "Li, Susie" , "Shan, Haitao" , "linux-kernel@vger.kernel.org" , "Dugger, Donald D" , "Auld, Will" , "xen-devel@lists.xensource.com" , "Nakajima, Jun" , "Zhang, Xiantao" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1635 Lines: 35 On Fri, Jun 22, 2012 at 4:21 PM, Luck, Tony wrote: >>>> 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. > > More bits can be added to MCG_CAP - but this becomes a hard > problem for migration because most OS guests only look at > MCG_CAP at boot time (linux certainly does) ... so if you migrate > and change MCG_CAP to match the new host, the guest will have > no idea that things changed. Typically if you have a heterogeneous pool (i.e., different processors with different CPUID bits) you typically have to calculate the minimum subset of features available on all processors and only expose those to the guest. It wouldn't be too hard to extend that to vMCEs if we had to. Alternately, as Jan says, we could just fake things out when we need to. -George -- 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/