Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2875929imm; Sun, 10 Jun 2018 03:41:43 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLKAnZwCEF4gkbiGeOIoJAsIWaxp4tNUeQ+CwUHFPlmB34fTF9eR729M+LtR0zWHZkfc+fc X-Received: by 2002:a17:902:5a4c:: with SMTP id f12-v6mr14092522plm.85.1528627303224; Sun, 10 Jun 2018 03:41:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528627303; cv=none; d=google.com; s=arc-20160816; b=MZjv69ApspmvTJ8cSx+TCb2OGY/9GR30mh1J6vrRyFMTr5lWeSYTtm8nvpeLGKEoS5 kEZB+7r1uBKryvOh3xFCJ/69FtMr7ndA88QhWbW4ts/Gn1IM2jxSQiO6jy9TlIizjJ3x buPaO6FutxBK8A8IfvaeUgPXe9Sc+FQXvkfg3q7MFCC7S1zzFCQkJP66HlyDTd31H6W7 2yEWGiGAdPP7C1dZYLnxaqEHdwYOkX2hDXcqF35r8W+30IpWZVy6HUV2eQQoQdLt4JzV Kx34mZy7p382QzFJsWJ/azkG+atTtVehTCP80LNOXrn7LhzYBH5X7AyGD6cjpqD3nQ2z 57Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:organization:user-agent :references:in-reply-to:subject:cc:to:from:message-id:date :arc-authentication-results; bh=ewUsGDyIHNb5YlU1zvqG08+HmxCagiT/gQDIZSqhb4U=; b=jufF30E/FIB+gV8VGcHW5WFjYtOjRUK5UjZam6ZrN6ZXtHYn2/ojUk089+GwJpoGGs rA1oMXXFvdVu2ODZGwKTtrni8oON3NRArNqfh+cDpTLR6nU2WRvukjQygSDJAZtjhjhx 3O1G2UFZ2X2e4StlaMqSx+i0sVmV76l3jMETcdanw1DbM3tjYDGDE4pOGOJxxJYT1cgv O1eqhJ1ZbQmspFbzPIahw6rqGT6eE4/VakXoApSOKUoqqF1YShcu1purqoPvouWuGqQw JtBEoBnjT/JcSTseL3cXg097ZWmi3IOMBByMdTNB9wNeXWZnPbm9hm0C/BZdgJESYAiM MNwA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g14-v6si19539894plq.41.2018.06.10.03.41.29; Sun, 10 Jun 2018 03:41:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753881AbeFJKlE (ORCPT + 99 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.