[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design



Here is the additional document that we mentioned on our proposal. It should be 
in close agreement with previous information and the discussion. 

Thanks,

Will 

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@xxxxxxxx] 
Sent: Tuesday, July 03, 2012 8:08 AM
To: Christoph Egger; Luck, Tony
Cc: IanCampbell; Raj, Ashok; Dugger, Donald D; Shan, Haitao; Liu, Jinsong; 
Nakajima, Jun; Li, Susie; Auld, Will; Zhang, Xiantao; Jiang, Yunhong; 
xen-devel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; KeirFraser
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design

>>> On 03.07.12 at 16:50, Christoph Egger <Christoph.Egger@xxxxxxx> wrote:
> On 07/03/12 15:26, Luck, Tony wrote:
> 
>>> I'm not convinced of the need, and would prefer aiming at a shared 
>>> implementation unless issues arise that make this impossible.
>> 
>> It does sound odd. Yes, Intel and AMD have differences around CMCI 
>> ... but
> we are never
>> going to send a CMCI to a guest (there is no point, it can't do 
>> anything
> useful with the
>> information, it may do something pointlessly stupid like stop using a 
>> guest
> physical page).
>> The only reason I suggested making MCG_CAP pretend that CMCI was 
>> supported
> was a
>> small optimization ... if a Linux guest sees that CMCI is supported, 
>> it will
> not poll the machine
>> check banks looking for corrected errors.
> 
> 
> Are you talking about PV or HVM guest?
> 
> For HVM guests yes it makes sense to disable CMCI in MCG_CAP for both 
> AMD and Intel.

"enable" you mean?

Jan

Attachment: XenMachineCheckArchitecturev0.5.pdf
Description: XenMachineCheckArchitecturev0.5.pdf

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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