From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: machine check support in HVM guests Date: Mon, 27 Nov 2006 14:13:20 +0000 Message-ID: <456B0090.76E4.0078.0@novell.com> References: <456AE849.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Oh, btw., are you implicitly telling me that forcing a GP fault on reads (and ideally also writes) of invalid MSRs then is also impossible? That is what I'm in the process of adding, at least for the case where Xen itself also receives a GP fault when reading the respective physical MSR. Jan >>> Keir Fraser 27.11.06 14:27 >>> On 27/11/06 12:29, "Jan Beulich" wrote: > Neither SVM nor VMX suppress CPUID[1].EDX.MC{E,A}, but there also is no > virtualization of the respective MSRs. Since the latter seems to have at best > marginal usefulness, shouldn't CPUID be respectively updated? Virtualisation of CPUID is currently back-to-front imo. We should be supplying an entirely fake CPUID space, filled in with native info only in places where that makes sense. Instead we supply native info, replaced with virtualised alternatives where that turns out to be needed. This, for example, means we cannot guarantee to support HVM guests with current Xen on future processors. They may extend the CPUID space in a way that current Xen does not understand and cause guests to try to use features that Xen does not virtualise or emulate. For your specific question, MCE/MCA used to be removed but 64-bit Windows requires this feature to be available (not sure if it's just for WHQL though). So we should emulate some basic MC support; enough to accept and discard MSR programming at least. -- Keir