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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 61E60C25B78 for ; Wed, 15 May 2024 09:35:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DxxY/0jcAv+/bl51r4jlFz8TbI0X/MgCJB593EfLqNI=; b=UH3MCvpphQVH8K IZ8ycy6SENR9uJmhGTlmqENC0m2pBfwWLHTOejVy6GaH67QrbZYF3dQlk/GySakyQjnqY2JMYDb4m NQOdg0tUI9GI6cJmvx1B28SogXWJsyCyoW0x+Rw13MhzPJ9LjO42fsqsJI2IALrV03k57SBz9WXRe 7r1zrsStjYJ6bmL1W2E5745H/NTCdEV5LYhCqfWiwIppiVV7FT7XSiHgW1E8JvBeghMcTo+BJDsro L5ZN5HFZDUE+Z0L7uyD2rcJ8jPSzgqd7pd3g62jffU3Bmc/Jd7/jwb5AW4V+6Le2CMqUYmh+SWrVN fRDDfDChwf3l1tm7gOOg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7B2C-00000001640-3AUb; Wed, 15 May 2024 09:34:52 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7B2A-00000001630-0IUK for linux-arm-kernel@lists.infradead.org; Wed, 15 May 2024 09:34:51 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 8B2DB6130C; Wed, 15 May 2024 09:34:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AC15C116B1; Wed, 15 May 2024 09:34:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715765689; bh=iV4NuC8nZ4r/lSpibzwon8OU9TtP6uytv5bsFJ9FtjM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DCC9ZrZKJhjrHUGxSfUVC2SuZ/tmBB59hL5/Wh8NqddWcYautGz3WQ69a5e8pLkGn nMZ7E8pOcxh1xFVnUvjzA60346MoR8A0GHaJisGGaeOxpy7dL/7LWaQN/EgeAizqS1 MK8PUVYS0P29ElLaicDr/h33+k/GLH8RU9LavbY2+yOEPkq/ZxuU6T6YdA4rHvN3FB q6c8e6Rp1mOxj7clTnGfTRYUhSLEWY8j4UuT8vaWVDyKq+hMdLmp5pW4GKMyje73U2 JvRBemGIJKvhaUm3J42+RRGYbki0P/cvzN82S10m76a0N7ijK5BqXwWXAYP/5YyAZu ZtMJJ949/OUKg== 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 1s7B26-00DLRm-L5; Wed, 15 May 2024 10:34:46 +0100 Date: Wed, 15 May 2024 10:34:46 +0100 Message-ID: <86v83fmn9l.wl-maz@kernel.org> From: Marc Zyngier To: Tangnianyao Cc: , , , , , jiangkunkun Subject: Re: [PATCH] irqchip/gic-v4.1:Check whether indirect table is supported in allocate_vpe_l1_table In-Reply-To: References: <20240122160607.1078960-1-tangnianyao@huawei.com> <86sf2p91zt.wl-maz@kernel.org> <5de3da53-9c0d-2a2d-876b-2181e540fa2f@huawei.com> <86r0i98o0a.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/29.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: tangnianyao@huawei.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, guoyang2@huawei.com, wangwudi@hisilicon.com, jiangkunkun@huawei.com 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-20240515_023450_222053_30F0C2FC X-CRM114-Status: GOOD ( 40.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 15 May 2024 09:56:10 +0100, Tangnianyao wrote: > > > > On 1/22/2024 22:02, Marc Zyngier wrote: > > On Mon, 22 Jan 2024 13:13:09 +0000, > > Tangnianyao wrote: > >> On 1/22/2024 17:00, Marc Zyngier wrote: > >>> [Fixing the LKML address, which has bits of Stephan's address embedded > >>> in it...] > >>> > >>> On Mon, 22 Jan 2024 16:06:07 +0000, > >>> Nianyao Tang wrote: > >>>> In allocate_vpe_l1_table, when we fail to inherit VPE table from other > >>>> redistributors or ITSs, and we allocate a new vpe table for current common > >>>> affinity field without checking whether indirect table is supported. > >>>> Let's fix it. > >>> Is there an actual implementation that doesn't support the indirect > >>> property for the VPE table? I know this is allowed for consistency > >>> with the original revision of the architecture, but I never expected > >>> an actual GICv4.1 implementation to be *that* bad. > >>> > >>> If that's the case, I'm a bit puzzled/worried. > >> I met this problem in a developing implementation and find it's allowed by GIC spec. > >> In such environment, in a common affinity field with only redistributors and without > >> any ITS in it, forcing its_vpe_id_alloc to allocate a large vpeid(like 65000), and there > >> comes an error message "VPE IRQ allocation failure". It originally comes from > >> allocate_vpe_l2_table, reading GICR_VPROPBASER with GICR_VPROPBASER_4_1_SIZE=1 > >> and GICR_VPROPBASER_4_1_INDIRECT=0. > > Really, you should get your HW engineers to fix their GIC > > implementation. I'm OK with working around this issue for > > completeness, but shipping such an implementation would be a mistake. > > > > [...] > > > >> I have another question here. The max number of pages for GITS_BASER > >> and GICR_VPROPBASER is different here, while GITS_BASER.Size is > >> bit[7:0] with max 256, and GICR_4_1_VPROPBASER.Size is bit[6:0] with max 128. > >> Kernel usually probe ITS basers first and then probe GICR_4_1_VPROPBASER in > >> a common affinity group. Maybe we need to check this in "inherit_vpe_l1_table_from_its" ? > > This is because GITS_BASER[] is generic (also works for devices and > > collections), while GICR_VPROPBASER is tailored to the VPE table which > > is usually smaller. > > > > I would expect that GICD_TYPER2.VID reports something that cannot > > result in something going wrong (in this case, the L1 allocation > > cannot be more than 128 pages). > > > > Overall, the kernel isn't a validation suite for the HW, and we expect > > it to have some level of sanity. So if none of this is in shipping HW > > but only in some model with crazy parameters, I don't think we should > > go out of our way to support it. > > > > Thanks, > > > > M. > > > > Hi Marc, > Friendly ping. Do we have plan to fix this problem on kernel, or any other plan ? Hi Nianyao, My earlier question still stand: is this something that affects a shipping implementation? If not, then I don't think we should support this upstream, as this doesn't seem like a realistic configuration. If your employer has actually built this (which I still consider as a mistake), then we can add the workaround I suggested. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel