From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754138Ab2DWRTQ (ORCPT ); Mon, 23 Apr 2012 13:19:16 -0400 Received: from terminus.zytor.com ([198.137.202.10]:54917 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751819Ab2DWRTP (ORCPT ); Mon, 23 Apr 2012 13:19:15 -0400 References: <20120421041454.GA29704@phenom.dumpdata.com> <20120421104502.GB17005@aftab.osrc.amd.com> <3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com> <4F958098.1050402@zytor.com> <20120423170327.GC22364@phenom.dumpdata.com> User-Agent: K-9 Mail for Android In-Reply-To: <20120423170327.GC22364@phenom.dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform From: "H. Peter Anvin" Date: Mon, 23 Apr 2012 10:16:16 -0700 To: Konrad Rzeszutek Wilk CC: "Luck, Tony" , "Liu, Jinsong" , "xen-devel@lists.xensource.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Borislav Petkov , Thomas Gleixner , Ingo Molnar , "linux-edac@vger.kernel.org" Message-ID: <45d73970-bf49-4695-8fe6-6f3c19e1097f@email.android.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org My biggest beefs are page table manipulation, all the extra ugliness in kernel entry and exit, and lack of clear initialization semantics. Additionally, any pvop which has unclear semantics - especially anything which is a nop on native and has zero documentation. Konrad Rzeszutek Wilk wrote: >On Mon, Apr 23, 2012 at 09:17:28AM -0700, H. Peter Anvin wrote: >> On 04/23/2012 08:27 AM, Luck, Tony wrote: >> >> Because, if you'd hooked into it, just imagine one fine day, when >we >> >> remove mcelog support, what screaming the xen people will be doing >when >> >> mcelog doesn't work anymore. >> > >> > Agreed. Even before we get to deleting mcelog, "struct mce" can >change (new >> > fields could be added) ... and you don't want to have your >hypervisor to >> > have to know which version of Linux it is talking to. >> >> This is a great example on the fundamental problem with Xen, or >rather >> the approach that Xen has taken of grabbing random kernel internals >and >> claiming them as APIs (or, in some cases even as ABIs.) A lot of >these > >I am _not_ claiming that. If I left you with that impression from my >responses - my fault for not getting my point across (the sleep >deprevation >is probably not helping either). > >I am _not_ stating that the usage of 'mce_log' or 'struct mce' MUST >remain the same from now on. No. I am saying that the driver will be >changed lock-step as Tony and Boris see fit in changing the functions. > >And currently the way the existing MCE drivers do this - is by using >mce_log. This driver does is too - since the in-tree drivers do it this >way. >When they change to use a different mechanism - this driver will as >well. > >> have had problems that are now very nearly unfixable, and that has >> seriously stalled out the ability of evolve the Linux kernel in some >> areas. Note that the cost of this is borne by the development >> community, not by the Xen maintainers. > >The ones I know that you are unhappy about are the MMU paravirt >interfaces >and I did mention to you that once some prototype work is done and >it showed success, I will work on removing said support. > >Why don't you send me your unhappy list so that is on my radar as well >please? > >> >> -hpa >> >> -- >> H. Peter Anvin, Intel Open Source Technology Center >> I work for Intel. I don't speak on their behalf. >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel -- Sent from my mobile phone. Please excuse brevity and lack of formatting.