[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] machine check support in HVM guests
> -----Original Message----- > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Keir Fraser > Sent: 27 November 2006 14:36 > To: Jan Beulich; Keir Fraser > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx > 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@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 > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |