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

[Keir Fraser <keir@xxxxxxxxxxxxx>]

No, I'm not saying that. I was simply expecting that it would be easy to
fake out a very minimal machine-check emulation where nothing ever goes
wrong. :-) If that involves GPFing on some MSR accesses, those are easy to
inject into an HVM guest I believe.

 -- Keir

On 27/11/06 14:13, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> 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 <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.
> 
> 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
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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