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 76C6FC4725D for ; Mon, 22 Jan 2024 14:03:38 +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=MUjMWr1ucPROYCw0tBQtgaLCcRcperD4VoB6mHPKrMo=; b=1BeEaSD+DXVzt/ E8YuzTgQfH2tC+XhdMuwpIq+58l5bYmd62PGjb5R0vnRRmL/TPta3dUUzIyVTMqarrR/vKrEHhLdv AvnffOSaRBkXwzTc1ZlECXkIRutD8IMEiHJE9TAP5xvMxl5UrV65v0bDLfgc3vxV4yqD7WVv5CGhU D7Hddr0BQxxDXdO4Sn9aiWFR0Mzh2KaE2ZQEV+D0tl0TNBl1FwM9iQfq4B3KK01Es7XIe7n5sFCEu idB/VxbPNr47bmEnKHUHfJODOS0ad2ftiCbtUWkQwCOOf1FgVn0PrWTujWUpamevV3c4wT+TxwK9Z el7MYTWXYf7caznykDjg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rRutH-00CLPb-1u; Mon, 22 Jan 2024 14:03:07 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rRutE-00CLOe-16 for linux-arm-kernel@lists.infradead.org; Mon, 22 Jan 2024 14:03:05 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7C7DE61491; Mon, 22 Jan 2024 14:02:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C0FBC43143; Mon, 22 Jan 2024 14:02:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705932153; bh=7tiMOZSQLb1z/spDB4FPLEENtPIT2Dt9gKufpl4mKys=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QnJRey3FVmS3J/JBWJ+ZyAeRBCCIhuc/p0CaRqEx0cJCO2hjELsI8+HVDyDnfe31W TEJYA1l45p6NWzMJfJRQkkpyXd35CZSqRZEaMncIpt/y03MGqqn/2aAcAFAqDtmH1q MSig1zTB4mRa8vLx5+N+qGpHkxpvtwKcc/lYHBa2qwz7wcegrId1zKj6fMfdX4niNR X52Z5seyij11UDz96hDcCy/udl/ru1hEZQdGGZNACwHnKIHzgBHsqxBX3K+h03biOR LWPizV66/CmjPeaJbsp8zf01a/5j4r6uQzhhgylXQZb6Pm1hegDMfYk6vMsfRV7m/3 K4fVpoBNT0fqg== 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 1rRusg-00DbLn-Ld; Mon, 22 Jan 2024 14:02:30 +0000 Date: Mon, 22 Jan 2024 14:02:29 +0000 Message-ID: <86r0i98o0a.wl-maz@kernel.org> From: Marc Zyngier To: Tangnianyao Cc: , , , , Subject: Re: [PATCH] irqchip/gic-v4.1:Check whether indirect table is supported in allocate_vpe_l1_table In-Reply-To: <5de3da53-9c0d-2a2d-876b-2181e540fa2f@huawei.com> References: <20240122160607.1078960-1-tangnianyao@huawei.com> <86sf2p91zt.wl-maz@kernel.org> <5de3da53-9c0d-2a2d-876b-2181e540fa2f@huawei.com> 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.1 (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 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-20240122_060304_463511_05CDB3A9 X-CRM114-Status: GOOD ( 30.23 ) 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 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. -- 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