WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] machine check support in HVM guests

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] machine check support in HVM guests
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Mon, 27 Nov 2006 14:10:50 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 27 Nov 2006 06:09:33 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C190983A.51BC%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <456AE849.76E4.0078.0@xxxxxxxxxx> <C190983A.51BC%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir@xxxxxxxxxxxxx> 27.11.06 14:27 >>>
>On 27/11/06 12:29, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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.

Indeed, that would be a lot better.

>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.

Ugly, because this means there is no way to implement it properly except by
either knowing what else assumptions Windows or other OSes make (bad) or
fully virtualizing it (cumbersome and pretty useless). Specifically, without
extra assumptions you cannot simply return zero for MSR reads, and you
cannot discard writes.

What I saw was that Linux tries to setup machine check MSRs, including on
or more registers that don't even exist in hardware (which leads to a
recoverable GP fault in Xen, which is what in fact caught my attention). That
I was thinking shouldn't happen at all, but if you want Windows to be able to
detect MCA, then we must be able to handle MCA reasonably for all possible
OSes.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel