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 07D0FCAC59A for ; Thu, 18 Sep 2025 09:50:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=4QvrVpKr3XvQJhacreBCRwMf/Y0fEtVFjOpfHwi7nmM=; b=aNfGQ3j8X28UukcrP5cUQgjUYb fcpXUTL16NBxFVVLXaDyCezGH9DKw1f3nLTpEcgjdyis0gfwfQIOgSLQfn3Z0qaU1RY7clwCsrOP8 xA3K/E4vMa2USXTRqhNDP97nVCK+dwM3aH5yHCJ18HznVmzOuB2PG3HlW9xkKmOa2TschMXhDW0T+ x6KKiNcBoVEBXS8zf4fZT9759/8RYgl2rwW6qMXLGHrQdzPHmBLWOSi4SPmNaSaR36A3sU2Kbjomb ygHWXH5fYBKoQXGnOhRXf4eaLgnsR+caqMJqRUapdSoCYs3/kLB6tZXrKRJKuTLDiByTr/Wu2FWfc krBYLstA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uzBHR-0000000GvsZ-25yL; Thu, 18 Sep 2025 09:50:21 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uzBHP-0000000GvsA-0ghd for linux-arm-kernel@lists.infradead.org; Thu, 18 Sep 2025 09:50:20 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 70DCA41794; Thu, 18 Sep 2025 09:50:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5010CC4CEE7; Thu, 18 Sep 2025 09:50:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1758189018; bh=LXlAjqvjLvki6S1N9v2AiSOCAG7MMsrq7HAkCVLpGQs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Ie+pdK/eamOD5NCz0wTJ+wGenyQbMS0eSX9/zA+LGYU4fL6UCU5BWod9iMiAuSUkl DtQnvBGhqU+mqERsXp29tTDoQ2j9OHGsWLmxsoqaese7Je9hjGFAJGdNtR/zjFcrAQ kg5Q8Eishh/u9JkQp6cEuaEhPw9HCz8/7iFR2MwCnGzSKVnj5DO/UB1BJlFsUHqL8e yYhVAPUtoB+UiCLx+6ybGtyWgA6JNE/9JPIiBBvH2fZklsO1H5iR0FnPeQxb5eCF+v NT4b7awXgTb5AeEdLyQMUUA9uQ02P/PZnvmiCMkX1zqJ5WEZxLHxZ2kI468V93GQQg lhMgrpiknx/8g== 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.98.2) (envelope-from ) id 1uzBHL-00000007NXy-42c3; Thu, 18 Sep 2025 09:50:16 +0000 Date: Thu, 18 Sep 2025 10:50:15 +0100 Message-ID: <86ldmc144o.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> <86v83fmn9l.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/30.1 (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: 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, wangzhou1@hisilicon.com, guozicheng3@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-20250918_025019_242732_49649C37 X-CRM114-Status: GOOD ( 47.36 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 18 Sep 2025 03:56:04 +0100, Tangnianyao wrote: > > > > On 5/15/2024 17:34, Marc Zyngier wrote: > > 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. > > > Hi Marc, > > For GIC4.1 of HIP09,HIP10,HIP10C, it only support one-level vcpu table and GITS_BASER.Indirect > is RAZ/WI. It implements page size 16KB and entry size 32B, each page support 512 vpe, and our > clients have requirement 1 or 2 pages at most, so it just supports flat page to simplify implementation. > > Our designer has confirmed with ARM architect that we can waive this rule: > Quote from GIC spec 12.19.1 GITS_BASER description, if the maximum width of the scaling factor > that is identified by GITS_BASER.Type and the smallest page size that is supported result in a single > level table that requires multiple pages, then implementing this bit > as RAZ/WI is DEPRECATED. I can read the spec just as well. Doesn't make it a good option. > We have actually built this in HIP09,HIP10,HIP10C and would like to > fix this in kernel. Isn't that the broken systems that can't even do vSGIs properly? > Can we merge the above bug-fix patch to kernel? Or we need to fix with errata for HIP09,HIP10,HIP10C? Frankly, I've completely lost track of what this patch is doing. This has been going on for over 18 months, and you have been silent on the subject for over a year. What do you expect? If you want anything to be done on this front, please repost a patch, and we'll review it again. M. -- Without deviation from the norm, progress is not possible.