[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.