From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.codeaurora.org by pdx-caf-mail.web.codeaurora.org (Dovecot) with LMTP id FObqG1v1HFtHXwAAmS7hNA ; Sun, 10 Jun 2018 10:41:07 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 4B2F960850; Sun, 10 Jun 2018 10:41:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by smtp.codeaurora.org (Postfix) with ESMTP id 999916070A; Sun, 10 Jun 2018 10:41:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 999916070A Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753885AbeFJKlE (ORCPT + 25 others); Sun, 10 Jun 2018 06:41:04 -0400 Received: from foss.arm.com ([217.140.101.70]:43442 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753535AbeFJKlC (ORCPT ); Sun, 10 Jun 2018 06:41:02 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 747A01529; Sun, 10 Jun 2018 03:41:02 -0700 (PDT) Received: from big-swifty.misterjones.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BEE3C3F25D; Sun, 10 Jun 2018 03:41:00 -0700 (PDT) Date: Sun, 10 Jun 2018 11:40:57 +0100 Message-ID: <86muw29b5y.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Hanjun Guo Cc: Yang Yingliang , , , Subject: Re: [PATCH v2] irqchip/gic-v3-its: fix ITS queue timeout In-Reply-To: References: <1528252824-15144-1-git-send-email-yangyingliang@huawei.com> <86a7s89t13.wl-marc.zyngier@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: ARM Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hanjun, On Thu, 07 Jun 2018 13:25:26 +0100, Hanjun Guo wrote: > > Hi Marc, > > On 2018/6/6 17:13, Marc Zyngier wrote: > [...] > > > > Wouldn't it be better to just return that the affinity setting request > > is impossible to satisfy? And more to the point, how comes we end-up > > in such a case? > > The system is booted with a NUMA node has no memory attaching to it > (memory-less NUMA node), also with NR_CPUS less than CPUs presented > in MADT, so CPUs on this memory-less node are not brought up, and > this NUMA node will not be online too. But the ITS attaching to this NUMA > domain is still valid and represented via SRAT to ITS driver. > > This is really the corner case which is triggered by the boot testing > when enabling our D06 boards, but it's a bug :) I'm not debating the bringing up (or lack thereof) of the secondary CPUs. I'm questioning the affinity setting to unavailable CPUs, and I really wonder what the semantic of such a thing is (and how we end-up there). Anyway, I'll plug the "SYNC to unmapped collection" issue (which definitely needs fixing), but I'd like to understand the above. Thanks, M. -- Jazz is not dead, it just smell funny.