From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933133Ab2GCPcW (ORCPT ); Tue, 3 Jul 2012 11:32:22 -0400 Received: from ch1ehsobe002.messaging.microsoft.com ([216.32.181.182]:35831 "EHLO ch1outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754755Ab2GCPcV (ORCPT ); Tue, 3 Jul 2012 11:32:21 -0400 X-Forefront-Antispam-Report: CIP:163.181.249.109;KIP:(null);UIP:(null);IPV:NLI;H:ausb3twp02.amd.com;RD:none;EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah) X-WSS-ID: 0M6LCHQ-02-HJ1-02 X-M-MSG: Message-ID: <4FF310C9.9040108@amd.com> Date: Tue, 3 Jul 2012 17:33:29 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: Jan Beulich CC: Tony Luck , IanCampbell , Ashok Raj , Donald D Dugger , Haitao Shan , Jinsong Liu , Jun Nakajima , Susie Li , Will Auld , Xiantao Zhang , Yunhong Jiang , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , KeirFraser Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design References: <4FEB236C020000780008C392@nat28.tlf.novell.com> <4FEC3B4A020000780008C673@nat28.tlf.novell.com> <4FEC463E020000780008C6A7@nat28.tlf.novell.com> <4FEC7FB8020000780008C885@nat28.tlf.novell.com> <4FED7C5F.1040908@amd.com> <4FF2B87C020000780008D3E0@nat28.tlf.novell.com> <3908561D78D1C84285E8C5FCA982C28F1933C278@ORSMSX104.amr.corp.intel<3908561D78D1C84285E8C5FCA982C28F1933C278@ORSMSX104.amr.corp.intel.com> <4FF306C1.7000100@amd.com> <4FF3270C020000780008D5A9@nat28.tlf.novell.com> In-Reply-To: <4FF3270C020000780008D5A9@nat28.tlf.novell.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/03/12 17:08, Jan Beulich wrote: >>>> On 03.07.12 at 16:50, Christoph Egger 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? Oh, sorry. I misread one sentence. If CMCI for the guest is really just emulated (= 100% software) then yes, enable for both AMD and Intel is fine. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632