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 7E117EB64D9 for ; Tue, 4 Jul 2023 16:03:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231574AbjGDQCz (ORCPT ); Tue, 4 Jul 2023 12:02:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231488AbjGDQCw (ORCPT ); Tue, 4 Jul 2023 12:02:52 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C3A210CF for ; Tue, 4 Jul 2023 09:02:48 -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 F180C612F0 for ; Tue, 4 Jul 2023 16:02:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E318C433C7; Tue, 4 Jul 2023 16:02:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688486567; bh=K6O4QE0VUWya7g8/u6RPt+8szEvhoKa/X2Dx+F5+88c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=c1lHn2THkohybSzBJUIFYn0e5Z5jZ01mHVjC/DXsf2mOax936+SRvOm0KykNCZuTw JO0V0rSO6UThqO+wVNJwvnh8nzaPrgQu40V0hmTbJHZ41DGpYh3o9t1UbE2arqEtDv 6dvT/SDXglOiNTPxh8uzB4EguPuB9d4KSm/c3ng3cziGZNIVpypw62kNTF/7uSWJbs US5VDo0rEJxZdvezo68ud3oPRkQKhfz5iVEkS5IfCPlnV8eOFIspBpZmbY0wfuPRQG /nsSQOrdHajGHz3WCn2vO3r1ZUrMtHk/fcJzgxhsUUFEUWOlx+a/dIaM88ucG8Hsw1 R8Kf+jGYn5uXA== 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 1qGiUH-00ATbr-1g; Tue, 04 Jul 2023 17:02:45 +0100 Date: Tue, 04 Jul 2023 17:02:44 +0100 Message-ID: <86pm57wtp7.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> <86wmzgx1va.wl-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 Tue, 04 Jul 2023 16:42:32 +0100, Zenghui Yu wrote: > > Hi Marc, > > On 2023/7/4 2:54, Marc Zyngier wrote: > > On Thu, 29 Jun 2023 15:52:24 +0100, > > Zenghui Yu wrote: > >> > >> Hi Marc, > >> > >> 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. > > [ I should've mentioned that I had reproduced the bug and tested your > patch on my 920, which is, yeah, a HiSi implementation of GICv4.0 with > DirectLPI supported. But ] > > > > > 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. > > ... iiuc the bug we're fixing is that we perform a register based > invalidation for doorbells (via its_vpe_[un]mask_irq/its_vpe_send_inv), > acquire and release the per-RD lock with a *race* against a concurrent > its_map_vm(), which would modify the vpe->col_idx behind our backs and > affect the lock we're looking for. > > its_vpe_[un]mask_irq() are callbacks for the v4.0 irqchip, i.e., > its_vpe_irq_chip. > > With v4.1, we switch to use its_vpe_4_1_irq_chip and invalidate > doorbells by sending the new INVDB command (and shouldn't be affected by > this bug). Gah, of course you're right. And we hardly ever invalidate DBs with v4.1 anyway since we can always say whether we want the doorbell or not when exiting residency on the RD (based on trapping WFI or not). Apologies for the noise, and thanks for putting me right! M. -- Without deviation from the norm, progress is not possible.