[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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. -- 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |