machine check support in HVM guests

machine check support in HVM guests

[Jan Beulich]

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?

Thanks, Jan

RE: machine check support in HVM guests

[Petersson, Mats]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Jan Beulich
> Sent: 27 November 2006 12:30
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] machine check support in HVM guests
> 
> 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?

I think masking those bits would be usefuller than implementing "machine
check virtualization", so "Yes". 

--
Mats
> 
> Thanks, Jan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 

Re: machine check support in HVM guests

[Keir Fraser]

On 27/11/06 12:29, "Jan Beulich" <jbeulich@novell.com> 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

Re: machine check support in HVM guests

[Jan Beulich]

>>> Keir Fraser <keir@xensource.com> 27.11.06 14:27 >>>
>On 27/11/06 12:29, "Jan Beulich" <jbeulich@novell.com> 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

Re: machine check support in HVM guests

[Jan Beulich]

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@xensource.com> 27.11.06 14:27 >>>
On 27/11/06 12:29, "Jan Beulich" <jbeulich@novell.com> 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

Re: machine check support in HVM guests

[Keir Fraser]

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@novell.com> 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@xensource.com> 27.11.06 14:27 >>>
> On 27/11/06 12:29, "Jan Beulich" <jbeulich@novell.com> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: machine check support in HVM guests

[Petersson, Mats]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Keir Fraser
> Sent: 27 November 2006 14:36
> To: Jan Beulich; Keir Fraser
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] machine check support in HVM guests
> 
> 
> 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.

Yupp, just one call to svm_inject_exception() - for some reason Intel's
side is a bit more confusing, as there seems to be about 4 different
types of exception injection code - not sure which is the right one. 

--
Mats
> 
>  -- Keir
> 
> On 27/11/06 14:13, "Jan Beulich" <jbeulich@novell.com> 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@xensource.com> 27.11.06 14:27 >>>
> > On 27/11/06 12:29, "Jan Beulich" <jbeulich@novell.com> 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@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 

Re: machine check support in HVM guests

[Jan Beulich]

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

That wasn't my concern, I know that's simple. But the guest may not be
prepared to handle a GP fault here - after all, if CPUID says MCA is
supported, there is no reason the guest should use recovery methods
around accessing the respective MSRs. Likewise, if returning zero, the
guest may BUG(), as it may (validly) assert there's at least one bank of
MSRs supported. And so on...

Jan

Re: machine check support in HVM guests

[Keir Fraser]

On 27/11/06 14:59, "Jan Beulich" <jbeulich@novell.com> wrote:

>> 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.
> 
> That wasn't my concern, I know that's simple. But the guest may not be
> prepared to handle a GP fault here - after all, if CPUID says MCA is
> supported, there is no reason the guest should use recovery methods
> around accessing the respective MSRs. Likewise, if returning zero, the
> guest may BUG(), as it may (validly) assert there's at least one bank of
> MSRs supported. And so on...

Then we support one bank of MSRs, store writes to those (so the contents can
be read back) but do not act on the writes? I never got the impression
machine check setup was very complicated.

 -- Keir

Re: machine check support in HVM guests

[Jan Beulich]

>Then we support one bank of MSRs, store writes to those (so the contents can
>be read back) but do not act on the writes? I never got the impression
>machine check setup was very complicated.

That may work, but doesn't have to.

(a) There might be (slightly broken) OS assumptions that a minimum number of
banks is available (since the banks serve different units within the CPU, this isn't
too unlikely an assumption).

(b) There might (now or in the future) be bits within the registers that have side
effects that OSes expect to happen.

So it'll have to be at least a little more complete than what you suggest (and I think
it'll end up being not to far from a version as complete as would be reasonable in
a virtualized environment). It's doable, certainly.

Jan