From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83832C2D0A3 for ; Thu, 12 Nov 2020 11:21:29 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0E362221FE for ; Thu, 12 Nov 2020 11:21:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OMJ71Aii"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="eZ+vrSim" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E362221FE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=KevhUPh9dhDS7jE54FzQLWHIbAQx/qaOuKfKbU4cdCk=; b=OMJ71AiiJfz7CE89T9A6KO5W6 fHA6L48igsc3gCyBd27DdEuxSHO1ZB5nA6zPd75NRsVDlCmZAud5H162aA9pEk2FKZqzW+CJxIzeM z1gtb+GFK5CVlhCoXI8ZeBFESSGFizMPoNS+fUyVAlOF7MkqFxR2QbSa72BWDuiP977AXymbPmsis bECcdMQGAeXhM/Yefo5jsx/OcIr7nSqeG+pSTEnYogHueJfH+8IR+i0eG09h/UDNsZD4d+Dt+Eocv 4ZBe5Oa4yV0IJUDJJdiigKoLoWdwOMPjeDl7o7ccAlvfq1KN9TXJmWzD5fjsm6ryCIURKdlLG3igG BtnGiZA0Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdAeE-0003Mn-Na; Thu, 12 Nov 2020 11:20:14 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdAeB-0003M1-W2 for linux-arm-kernel@lists.infradead.org; Thu, 12 Nov 2020 11:20:13 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8D8DC21D40; Thu, 12 Nov 2020 11:20:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605180010; bh=K8snTlzRrBmCFb3kcN8jLGjUTIdHXOt33Jd0fecxr4g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eZ+vrSimKFesca0wJwgzMJ8ZkL/HxvQN5r3Cen8yfqrxZlfrAwmEcmDo2TKcJZE9+ 7kgR/DVURdNy2KRbVFtbrK+nV+XFGksDkpdo5YLxVvx7xj8L1VWE6rndL6M+7v2uYg lfZdQWkZJN9TLtm7FbCbfu/eHqp3cKe8nLkyqy/U= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kdAe8-00A17J-CY; Thu, 12 Nov 2020 11:20:08 +0000 MIME-Version: 1.0 Date: Thu, 12 Nov 2020 11:20:08 +0000 From: Marc Zyngier To: Lorenzo Pieralisi Subject: Re: [PATCH 1/2] arm64: cpufeature: Add GIC CPUIF v4.1 detection In-Reply-To: <20201111162841.3151-2-lorenzo.pieralisi@arm.com> References: <20201111162841.3151-1-lorenzo.pieralisi@arm.com> <20201111162841.3151-2-lorenzo.pieralisi@arm.com> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <89291c496e6e868c442f5763db53d22d@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: lorenzo.pieralisi@arm.com, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201112_062012_367141_3FB59AA2 X-CRM114-Status: GOOD ( 22.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, LAKML Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-11-11 16:28, Lorenzo Pieralisi wrote: > GIC v4.1 introduced changes to the GIC CPU interface; systems that > integrate CPUs that do not support GIC v4.1 features (as reported in > the > ID_AA64PFR0_EL1.GIC bitfield) and a GIC v4.1 controller must disable in > software virtual SGIs support since the CPUIF and GIC controller > version > mismatch results in CONSTRAINED UNPREDICTABLE behaviour at > architectural > level. > > Add a cpufeature and related capability to detect GIC v4.1 CPUIF > features so that the GIC driver can probe it to detect GIC CPUIF > hardware configuration and take action accordingly. > > Signed-off-by: Lorenzo Pieralisi > Cc: Will Deacon > Cc: Catalin Marinas > Cc: Marc Zyngier > --- > arch/arm64/include/asm/cpucaps.h | 3 ++- > arch/arm64/kernel/cpufeature.c | 10 ++++++++++ > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/cpucaps.h > b/arch/arm64/include/asm/cpucaps.h > index 42868dbd29fd..35ef0319f422 100644 > --- a/arch/arm64/include/asm/cpucaps.h > +++ b/arch/arm64/include/asm/cpucaps.h > @@ -65,7 +65,8 @@ > #define ARM64_HAS_ARMv8_4_TTL 55 > #define ARM64_HAS_TLB_RANGE 56 > #define ARM64_MTE 57 > +#define ARM64_HAS_GIC_CPUIF_VSGI 58 > > -#define ARM64_NCAPS 58 > +#define ARM64_NCAPS 59 > > #endif /* __ASM_CPUCAPS_H */ > diff --git a/arch/arm64/kernel/cpufeature.c > b/arch/arm64/kernel/cpufeature.c > index dcc165b3fc04..9eabbaddfe5e 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -2136,6 +2136,16 @@ static const struct arm64_cpu_capabilities > arm64_features[] = { > .cpu_enable = cpu_enable_mte, > }, > #endif /* CONFIG_ARM64_MTE */ > + { > + .desc = "GIC CPUIF virtual SGI", nit: that's not really what this feature is. It only means that the sysreg interface complies to v4.1. Which on its own is totally rubbish, because the sysreg don't change behaviour between 3.0/4.0 and 4.1. > + .capability = ARM64_HAS_GIC_CPUIF_VSGI, > + .type = ARM64_CPUCAP_BOOT_CPU_FEATURE, > + .matches = has_cpuid_feature, > + .sys_reg = SYS_ID_AA64PFR0_EL1, > + .field_pos = ID_AA64PFR0_GIC_SHIFT, > + .sign = FTR_UNSIGNED, > + .min_field_value = 3, > + }, Do we really need a new cap for that? Or can we rely on simply looking at the sanitised feature set? I'm not overly keen on advertising a feature at CPU boot time if we discover later on that we cannot use it because all we have in a non-4.1 GIC. Another thing is that we currently assume that *all* CPUs will be the same at the point where we setup the GIC (we only have a single CPU booted at that point). M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel