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