Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp492677yba; Thu, 9 May 2019 01:00:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqxzFe2ApU3fkMH4RnfLl1QFkbXOM4wj2k3SpsgA/huq8fZ2XVdUUkUPL2D47pHN02n6ges4 X-Received: by 2002:aa7:81d0:: with SMTP id c16mr3055510pfn.132.1557388804622; Thu, 09 May 2019 01:00:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557388804; cv=none; d=google.com; s=arc-20160816; b=dARB9B0nvrWrh49M/bLK4E/GcpFnYGDBQfXcRYr0dlG/0lmlYmDt8jYeIRe7o8Ing1 SPfuB1zE0ZQKEUhndQgiiZ62VkDui0JWoDN0gIeStX1aD8wgYUiaHDCUg6dsvJh0EXiM NWRg0S8hVMqhwftK/zBFHFO6nXhSH856Cg/h2NfI2lsWJPW0nZhaNqT4IYxMeZxQIb8V f/IY40ZuRkShL4BSxAI2lNLEoDz+qodhdoFtAPZ2K3kL3w3oghzMmb6FvFWp4T0CqRNt Ct7Oy+ICFtfaj67t0iFVBIzX0eXTLlRrcmHxRO+3IET2HnbKxiEKiTE3Mlj5S3ADYAIU vSeQ== 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; bh=tHRuLQ+108WBPbA1pALY0cmwd+8R0ywjS4hm21XOMy8=; b=qFWfrrnHbShy4Q5hQv+EYZsA/KLuII3JaySicjHmEDFnZcnMcDgb78tI6KuMZLlwO3 cWhw/SzrA+UiwHlKfNpDHCtxFeNccsyKwoeYjKo9LBSeAHSPqj62kp5BdcYInVyfUHz1 ncRIBh1Dv6ZyfbhXKZ5V3qJKPtrKXz8jsRnhpxi4V397yIDZyRfveVaqr3S2uVYDgEGw EHIukj3JDP5WYaGAjwtAKd7z1SrzHvgpe2MlH67ALLQjIg6ivIScmTxwDPywNBJk1PZa EzNQepV4uzKrLHffp2JZcbNf5jC9pfZBF+CxBY6gVCed77LeDVKuz1iz8nRBvXZSzIP3 +YXA== 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 y8si2090529pgr.27.2019.05.09.00.59.48; Thu, 09 May 2019 01:00:04 -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 S1726571AbfEIH67 (ORCPT + 99 others); Thu, 9 May 2019 03:58:59 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:33230 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725822AbfEIH67 (ORCPT ); Thu, 9 May 2019 03:58:59 -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 CD5C7A78; Thu, 9 May 2019 00:58:56 -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 C83AB3F7BD; Thu, 9 May 2019 00:58:45 -0700 (PDT) Date: Thu, 09 May 2019 08:58:23 +0100 Message-ID: <867eb09i00.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Heyi Guo Cc: , Christoffer Dall , wanghaibin 00208455 Subject: Re: Why do we mark vpending table as non-shareable in GICR_VPENDBASER? In-Reply-To: References: 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/26 (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 On Thu, 09 May 2019 08:10:09 +0100, Heyi Guo wrote: > > Hi Marc, > > We can see in its_vpe_schedule() the shareability bits of > GICR_VPENDBASER are set as non-shareable, But we set physical > PENDBASER as inner-shareable. Is there any special reason for doing > this? If it is because the vpending table is GICR specific, why > don't we do the same for physical pending table? That's a good question. They should have similar attributes. > We have not seen function issue with this setting, but a special > detector in our hardware warns us that there are non-shareable > requests sent out while some inner shareable cache entries still > present in the cache, and it may cause data inconsistent. The main issue with the inner-shareable attributes and the GIC is that nothing in the spec says that CPUs and GIC have to be in the same inner-shareable domain, as the system can have as many as you want. You obviously have built it with GICR in the same inner-shareability domain as the CPU. I'm happy to change the VPENDBASER attributes, given that the CPU has a mapping to that memory already, and that shouldn't affect systems where GICR isn't in the same inner shareable domain anyway. Thanks, M. -- Jazz is not dead, it just smell funny.