Received: by 2002:a05:6a10:83d0:0:0:0:0 with SMTP id o16csp192995pxh; Thu, 7 Apr 2022 18:31:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwxT+lyGkCFvq9d5zdufTxa/94c7V3+VizEPehDBO0Ua77lWnUoXAVzwh/oaibGXXKmluLj X-Received: by 2002:a17:902:d492:b0:157:812:e784 with SMTP id c18-20020a170902d49200b001570812e784mr5958233plg.2.1649381490472; Thu, 07 Apr 2022 18:31:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649381490; cv=none; d=google.com; s=arc-20160816; b=lvcfwdD0uEYj50PPEiQic7ekOsBcqc1INVc5y7klL1Q5x7hp1pOL/BPGUiS0do49W6 qYS/c5RXSe69gleGiWQGdAefgHzIN9MMExpNrd2QZBOghm35H7opJxZ1zJx/H7PvnGDZ B78SBsrsyoO9IyhGnogMMsZHcgM8fXhvGVfP4wxhIJFXk+I5QLky+1hJtlRpZchVknMD lF/CGj+HYEhx+db2WULacx4QbOOWjLTd7PmiCTrocuFRtvrq2zGGyUW/oTfAVoLdsUrm e86XEj5Cd7pMT48QgPqGItNBbHpLdYIXuJ8UxQ4MAvl0gBBmHCAUh3pxLIGaowIQapxa Cakg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=knyWIWFX6jWltCEAW9OsOAeL5At4ayufF3TmSVR0PWU=; b=CRDR5ihiegWaS//ju00fGWGwnret9VfMv/Yk6wYfOxAT4zYJ5xfsfr86MmC4qknh4u 1RQ1qgsCmK26WKXc0/X45MKn06/4wvKrwqleYxP7V/WdqD4zB9os8FZLw6QCvFDpZix+ pyPJsj7IiQga8i5uFffZRMvMyUsXubET+K++vKj3jwTjFK5mqKjcZNNxF0pzbLTWd8DX OUM75aB+ReHosAVQo1fddKjma2gAasEmioydlc9vf88lXJK9IW+mCeymNiY3+CtvmOiH C5m2iuIafvL6HApXmZtM8SoX7MRoPHlRlevIXsstJEflfbsD45Y97AiqNRmPWtkmrUEg bcLA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id p19-20020a056a000a1300b004fa3a8e004bsi20780970pfh.258.2022.04.07.18.31.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 18:31:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DEF4B21B2E5; Thu, 7 Apr 2022 18:02:28 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233202AbiDHBEZ (ORCPT + 99 others); Thu, 7 Apr 2022 21:04:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230169AbiDHBEY (ORCPT ); Thu, 7 Apr 2022 21:04:24 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A671E219AD0 for ; Thu, 7 Apr 2022 18:02:21 -0700 (PDT) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KZKg52BYSzgYVD; Fri, 8 Apr 2022 09:00:33 +0800 (CST) Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 8 Apr 2022 09:02:18 +0800 Received: from [10.174.179.5] (10.174.179.5) by dggpemm500002.china.huawei.com (7.185.36.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 8 Apr 2022 09:02:18 +0800 Subject: Re: [PATCH v3 0/3] genirq: Managed affinity fixes To: John Garry , Marc Zyngier , linux-kernel CC: Thomas Gleixner , David Decotigny References: <20220405185040.206297-1-maz@kernel.org> From: Xiongfeng Wang Message-ID: Date: Fri, 8 Apr 2022 09:02:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.5] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500002.china.huawei.com (7.185.36.229) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 2022/4/8 1:29, John Garry wrote: > On 05/04/2022 19:50, Marc Zyngier wrote: >> John (and later on David) reported[1] a while ago that booting with >> maxcpus=1, managed affinity devices would fail to get the interrupts >> that were associated with offlined CPUs. >> >> Similarly, Xiongfeng reported[2] that the GICv3 ITS would sometime use >> non-housekeeping CPUs instead of the affinity that was passed down as >> a parameter. >> >> [1] can be fixed by not trying to activate these interrupts if no CPU >> that can satisfy the affinity is present (a patch addressing this was >> already posted[3]) >> >> [2] is a consequence of affinities containing non-online CPUs being >> passed down to the interrupt controller driver and the ITS driver >> trying to paper over that by ignoring the affinity parameter and doing >> its own (stupid) thing. It would be better to (a) get the core code to >> remove the offline CPUs from the affinity mask at all times, and (b) >> fix the drivers so that they can trust the core code not to trip them. >> >> This small series, based on 5.18-rc1, addresses the above. > > Hi Marc, > > Please let me know if you require anything more from me on this one. I was > hoping that Xiongfeng would verify that his "housekeeping" issues were fixed. I have tested the V2 version. It works well and fixed both issues, the 'maxcpus=1' issue and 'housekeeping' issue. Let me know if you need me test this V3 version. I am not seeing much change, only context change. Thanks, Xiongfeng > > Cheers > >> >> Thanks, >> >>     M. >> >>> From v2 [4]: >>    - Rebased on 5.18-rc1 >> >> [1] https://lore.kernel.org/r/78615d08-1764-c895-f3b7-bfddfbcbdfb9@huawei.com >> [2] https://lore.kernel.org/r/20220124073440.88598-1-wangxiongfeng2@huawei.com >> [3] https://lore.kernel.org/r/20220307190625.254426-1-maz@kernel.org >> [4] https://lore.kernel.org/r/20220321193608.975495-1-maz@kernel.org >> >> Marc Zyngier (3): >>    genirq/msi: Shutdown managed interrupts with unsatifiable affinities >>    genirq: Always limit the affinity to online CPUs >>    irqchip/gic-v3: Always trust the managed affinity provided by the core >>      code >> >>   drivers/irqchip/irq-gic-v3-its.c |  2 +- >>   kernel/irq/manage.c              | 25 +++++++++++++++++-------- >>   kernel/irq/msi.c                 | 15 +++++++++++++++ >>   3 files changed, 33 insertions(+), 9 deletions(-) >> > > .