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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 258FBC001B3 for ; Mon, 3 Jul 2023 18:55:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231137AbjGCSzN (ORCPT ); Mon, 3 Jul 2023 14:55:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230250AbjGCSzL (ORCPT ); Mon, 3 Jul 2023 14:55:11 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93DA110D9 for ; Mon, 3 Jul 2023 11:54:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5615F60FFA for ; Mon, 3 Jul 2023 18:54:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B02FFC433C8; Mon, 3 Jul 2023 18:54:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688410443; bh=SEKBMg3chV7met+vgORs+906H4nzp+RO5Hm59v64Jj0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XTfoCo0qlatCxo8uhhtnUeVPZLr0bGhBxDrJX2o9GnhcJnHEas3iQjs3v0Ssji9Fr d3xt/nAG6UjEn2KoFHkVpT4YstgavD3Ef5cQaB+9XalmjxkmkmiIUFzwASJEUD4au5 bUmAJnOn8MfI1uMHMWtOxoxipPU8a7bdl4+pY9uI0l/2TVWKkVPoMr3yiLEkR0RvPt 6qYr/GhvnHwdnHzMza9fZJG37l9H3b73O2e6pk6aTCnBMmdeVMUIt/aJ1MHUF3A+kt JntiL04FWn5q6rNJpLaSx2lDJrfRgV8Tpmxw7FeEzLDovMDqbnKmlhKMb7B2T9LIXL EBHyUnFrIC7/g== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qGOgT-00AFAN-Hq; Mon, 03 Jul 2023 19:54:01 +0100 Date: Mon, 03 Jul 2023 19:54:01 +0100 Message-ID: <86wmzgx1va.wl-maz@kernel.org> From: Marc Zyngier To: Zenghui Yu Cc: , Thomas Gleixner , Kunkun Jiang , Subject: Re: [PATCH] irqchip/gic-v4.1: Properly lock VPEs when doing a directLPI invalidation In-Reply-To: References: <20230617073242.3199746-1-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: yuzenghui@huawei.com, linux-kernel@vger.kernel.org, tglx@linutronix.de, jiangkunkun@huawei.com, wanghaibin.wang@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Jun 2023 15:52:24 +0100, Zenghui Yu wrote: > > Hi Marc, > > On 2023/6/17 15:32, Marc Zyngier wrote: > > We normally rely on the irq_to_cpuid_[un]lock() primitives to make > > sure nothing will change col->idx while performing a LPI invalidation. > > "change col_idx while performing a vLPI invalidation"? > > > However, these primitives do not cover VPE doorbells, and we have > > some open-coded locking for that. Unfortunately, this locking is > > pretty bogus. > > > > Instead, extend the above primitives to cover VPE doorbells and > > convert the whole thing to it. > > > > Fixes: f3a059219bc7 ("irqchip/gic-v4.1: Ensure mutual exclusion between vPE affinity change and RD access") > > Reported-by: Kunkun Jiang > > Signed-off-by: Marc Zyngier > > Cc: Zenghui Yu > > Cc: wanghaibin.wang@huawei.com > > Reviewed-by: Zenghui Yu Thanks! > > Nit: I think the Subject header can be changed to 'irqchip/gic-v4' as > the bug it fixes only affects GICv4 HW. v4.1 is unaffected. I'm not so sure. v4.0 didn't allow direct invalidation of VPE doorbells (we had to use the fake device hack), except for the HiSi special that implemented DirectLPI despite the presence of multiple ITSs. It was a violation of the architecture, but it really saved the day by making invalidations cheap enough. Only with v4.1 did we get architectural support for doorbell invalidation via a register instead of a command for a fake device. So as far as the architecture is concerned, this should only affect v4.1. As a side effect, it also affect HiSi's v4.0 implementations. Or am I missing something? Cheers, M. -- Without deviation from the norm, progress is not possible.