Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5307067imm; Tue, 26 Jun 2018 09:04:54 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLZClKvGXcQu/rtMIVda6Zz8OM0xLhGP3ylzvivudcEluSAgGdM7jqtD+yCp3P6zqrC6VN7 X-Received: by 2002:a63:b91c:: with SMTP id z28-v6mr1965786pge.22.1530029094434; Tue, 26 Jun 2018 09:04:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530029094; cv=none; d=google.com; s=arc-20160816; b=klwZ37Zaryiy3vukvLhgTg5scj9c8ck7VVjKodSDDNHhcyxU5dDCP44GaBquIXyuGH un8ecO27vK3EBIMy/GeC0YCtulY4JLS/HEo0f3ghJ+/x9sZeRybUwTfV2VBqqyjy6IvA LDu77v+zNwZPdVU/WUFusM+mOvXCYx3dPYNC8s0NQg0UJj03KVs5l+waLvsxfnoHjvb+ RkmNOK/YDHXJ5+xalTm67sFrXo10nlGljXcsLiwj3Xy0KUr4qad47Te8qFDcjV5YP/HB Az/ED/kXkAPcp3lTuKbZe/R+0/GJnZdo7les4S0nnFSMqijPnPwxTDBoZdsyCe0s6n/K 6s4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=zaYctDFEzmLZjVLf8Bxh9U8OYRvN7l6d8aXIa/88OzM=; b=ajzW346dreSijywJSgOjxYjTMypTPTmHgfpQ4YBYCmMzMVl8fAq3+ydUc8bZei0I09 Jyo37jGdWLUNbTRYZb/pAw8vkV79FFQu5/I9L7POa4JKj6kQV1zgR/gXd1ZVqdCjkmcN c1t+8ptYhyw7EDA+ppUsevUzVaGGpIcO1wJUoQ0T+nYQvmg+6Wt2zcWjbJJDW3ttI5qP xuaRA77CmqSbihwCd2Y/J4YKHn8qk1sEdVEHltOUKuHHw45cevdVq/uTbBlB3Z+QRASD NqpKo1vsZtQNxYI9SyJZ7sB5LpU9q7zpezoA625CeZ+toDIf4WtAYc1m6DX/W4Tt4rNu WDKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w11-v6si1744993plz.333.2018.06.26.09.04.36; Tue, 26 Jun 2018 09:04:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936095AbeFZO3y (ORCPT + 99 others); Tue, 26 Jun 2018 10:29:54 -0400 Received: from mail.skyhub.de ([5.9.137.197]:51356 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935339AbeFZO3x (ORCPT ); Tue, 26 Jun 2018 10:29:53 -0400 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fdbsMcMnNCMh; Tue, 26 Jun 2018 16:29:52 +0200 (CEST) Received: from zn.tnic (p200300EC2BCA5B00329C23FFFEA6A903.dip0.t-ipconnect.de [IPv6:2003:ec:2bca:5b00:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 33B681EC01D4; Tue, 26 Jun 2018 16:29:52 +0200 (CEST) Date: Tue, 26 Jun 2018 16:29:49 +0200 From: Borislav Petkov To: David Wang Cc: tony.luck@intel.com, mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, cooperyan@zhaoxin.com, qiyuanwang@zhaoxin.com, benjaminpan@viatech.com, lukelin@viacpu.com, timguo@zhaoxin.com Subject: Re: [PATCH v2] x86/mce: add CMCI support for Centaur CPUs Message-ID: <20180626142949.GA4136@zn.tnic> References: <1528079853-8101-1-git-send-email-davidwang@zhaoxin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1528079853-8101-1-git-send-email-davidwang@zhaoxin.com> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 04, 2018 at 10:37:33AM +0800, David Wang wrote: > New Centaur CPU support CMCI mechanism, which is compatible with INTEL CMCI. > > Signed-off-by: David Wang ... > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c > index cd76380..2ebafc7 100644 > --- a/arch/x86/kernel/cpu/mcheck/mce.c > +++ b/arch/x86/kernel/cpu/mcheck/mce.c > @@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c) > } > } > > +#ifdef CONFIG_X86_MCE_CENTAUR > static void mce_centaur_feature_init(struct cpuinfo_x86 *c) > { > struct mca_config *cfg = &mca_cfg; > @@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct cpuinfo_x86 *c) > if (cfg->monarch_timeout < 0) > cfg->monarch_timeout = USEC_PER_SEC; > } > + mce_intel_feature_init(c); > + mce_adjust_timer = cmci_intel_adjust_timer; This ... > } > +#else > +static inline void mce_centaur_feature_init(struct cpuinfo_x86 *c) { } > +#endif > > static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c) > { > diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c b/arch/x86/kernel/cpu/mcheck/mce_intel.c > index d05be30..5b1b68f 100644 > --- a/arch/x86/kernel/cpu/mcheck/mce_intel.c > +++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c > @@ -85,7 +85,8 @@ static int cmci_supported(int *banks) > * initialization is vendor keyed and this > * makes sure none of the backdoors are entered otherwise. > */ > - if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) > + if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL && > + boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR)) > return 0; > if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6) > return 0; > @@ -506,10 +507,20 @@ static void intel_ppin_init(struct cpuinfo_x86 *c) > > void mce_intel_feature_init(struct cpuinfo_x86 *c) > { > - intel_init_thermal(c); > - intel_init_cmci(); > - intel_init_lmce(); > - intel_ppin_init(c); > + > + switch (c->x86_vendor) { > + case X86_VENDOR_INTEL: > + intel_init_thermal(c); > + intel_init_cmci(); > + intel_init_lmce(); > + intel_ppin_init(c); > + break; > + case X86_VENDOR_CENTAUR: > + intel_init_cmci(); ... and this I really don't like for the simple reason that if the Intel side gets changed, it could potentially break Centaur. And we don't want that. And the vendor should be free to change their code without asking another vendor for permission even if the other vendor is almost copying the code... Long story short, I think you should extract the facilities you're going to need into generic, library-like ones and call them from centaur-specific compilation units which get enabled when CPU_SUP_CENTAUR is enabled. So that the code can still be shared but there's no dependency on other vendors and so that one vendor doesn't break the other one and vice-versa. IMO. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.