Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp810820ybg; Wed, 23 Oct 2019 06:14:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqzL939zbUh4vnGVe/uUs3dZB6Jvfz8miyqJHkc7Zn7HYGeEsQurdMWVDe1HMEi7pI6slNW1 X-Received: by 2002:a17:906:27c5:: with SMTP id k5mr32155480ejc.173.1571836449381; Wed, 23 Oct 2019 06:14:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571836449; cv=none; d=google.com; s=arc-20160816; b=lPL8irryW4MiHmYx1KufkZur6KNbAXu4YL5T81KD04AtJvzAjMjeAZ2+LoaVd9q4we Ud3k0xfUBFcqjeT9MqDdwYjK5ywRgeAoHGv2U/rYmIOGRnE7jBkv233ZjN+fTDIpjFsP n2meev5M6NG2igJTnmoL9eruJvw+kRo5YAhpZpbp4OtebeNXz9KDi//i2y9PLTrMcL7q tP7CIabfI+fb3C6uT+lCpSshSFqxm9U9aEYQUiWgjqdd9QUrpA4aJMGmLW/+PVk5hyly 7MhOvLSbgkyst2rV5Jj0s656XFNVO4jWWlx3mCCzLhmtaXvH+EK2ozH4lcPL3TUNi9o3 mdwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:cc:from:date:content-transfer-encoding:mime-version :subject:to; bh=7jSema9CJG8K8fcXswpS8TRlT/5Ili1JlOji5Usy4uM=; b=Ut+AkYY2eoQjC9RrwsneFAYvs6d/ivKeevmHHjrrEvC3DR06EnEOcBXNWhwHLqeyKm YqI+Yzday1gcu1gOyP8AorDGljoRQl9ikyt+I0EzS2FgilqID3aOR6he97T8/yfGjMkK ao5UsMqn+PsTi6VSSbjThRi7eElt6zwe0hDArDI1jjb1IgANRuZnzgH9lizaJ16arkXz aNg9H7IUbJ+1bTgVvVgRSBmljrhOd2/r8r3KTFDEAl7Rz71qdiJ1vc/uZuiULgr3UThy zejxoDwfXU/ysZC5r3dBre+jpPpJ/A4vIQ7vr+WbsBZjw/4ZL55fHGuCTL3mXvkAjpdp cqsA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p5si6911526ejx.100.2019.10.23.06.13.42; Wed, 23 Oct 2019 06:14:09 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733136AbfJWMNX (ORCPT + 99 others); Wed, 23 Oct 2019 08:13:23 -0400 Received: from inca-roads.misterjones.org ([213.251.177.50]:49339 "EHLO inca-roads.misterjones.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726925AbfJWMNW (ORCPT ); Wed, 23 Oct 2019 08:13:22 -0400 Received: from www-data by cheepnis.misterjones.org with local (Exim 4.80) (envelope-from ) id 1iNFVq-0001TZ-BF; Wed, 23 Oct 2019 14:13:14 +0200 To: "liwei (GF)" Subject: Re: [PATCH v3 1/2] arm64: Relax =?UTF-8?Q?ICC=5FPMR=5FEL=31=20acc?= =?UTF-8?Q?esses=20when=20ICC=5FCTLR=5FEL=31=2EPMHE=20is=20clear?= X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Oct 2019 13:13:14 +0100 From: Marc Zyngier Cc: Will Deacon , Catalin Marinas , Suzuki K Poulose , James Morse , Julien Thierry , , , , In-Reply-To: References: <20191002090613.14236-1-maz@kernel.org> <20191002090613.14236-2-maz@kernel.org> Message-ID: <4ed2ed389a81cc0ec6f3150ce38517a5@www.loen.fr> X-Sender: maz@kernel.org User-Agent: Roundcube Webmail/0.7.2 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: liwei391@huawei.com, will@kernel.org, catalin.marinas@arm.com, suzuki.poulose@arm.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, huawei.libin@huawei.com, guohanjun@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on cheepnis.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Wei, On 2019-10-23 09:38, liwei (GF) wrote: > Hi Marc, > > On 2019/10/2 17:06, Marc Zyngier wrote: >> The GICv3 architecture specification is incredibly misleading when >> it >> comes to PMR and the requirement for a DSB. It turns out that this >> DSB >> is only required if the CPU interface sends an Upstream Control >> message to the redistributor in order to update the RD's view of >> PMR. >> >> This message is only sent when ICC_CTLR_EL1.PMHE is set, which isn't >> the case in Linux. It can still be set from EL3, so some special >> care >> is required. But the upshot is that in the (hopefuly large) majority >> of the cases, we can drop the DSB altogether. >> >> This relies on a new static key being set if the boot CPU has PMHE >> set. The drawback is that this static key has to be exported to >> modules. >> >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: James Morse >> Cc: Julien Thierry >> Cc: Suzuki K Poulose >> Signed-off-by: Marc Zyngier >> --- >> arch/arm64/include/asm/barrier.h | 12 ++++++++++++ >> arch/arm64/include/asm/daifflags.h | 3 ++- >> arch/arm64/include/asm/irqflags.h | 19 ++++++++++--------- >> arch/arm64/include/asm/kvm_host.h | 3 +-- >> arch/arm64/kernel/entry.S | 6 ++++-- >> arch/arm64/kvm/hyp/switch.c | 4 ++-- >> drivers/irqchip/irq-gic-v3.c | 20 ++++++++++++++++++++ >> include/linux/irqchip/arm-gic-v3.h | 2 ++ >> 8 files changed, 53 insertions(+), 16 deletions(-) >> >> diff --git a/arch/arm64/include/asm/barrier.h >> b/arch/arm64/include/asm/barrier.h >> index e0e2b1946f42..7d9cc5ec4971 100644 >> --- a/arch/arm64/include/asm/barrier.h >> +++ b/arch/arm64/include/asm/barrier.h >> @@ -29,6 +29,18 @@ >> SB_BARRIER_INSN"nop\n", \ >> ARM64_HAS_SB)) >> >> +#ifdef CONFIG_ARM64_PSEUDO_NMI >> +#define pmr_sync() \ >> + do { \ >> + extern struct static_key_false gic_pmr_sync; \ >> + \ >> + if (static_branch_unlikely(&gic_pmr_sync)) \ >> + dsb(sy); \ >> + } while(0) >> +#else >> +#define pmr_sync() do {} while (0) >> +#endif >> + > > Thank you for solving this problem, it helps a lot indeed. > > The pmr_sync() will call dsb(sy) when ARM64_PSEUDO_NMI=y and > gic_pmr_sync=force, > but if pseudo nmi is not enabled through boot option, it just take > one more > redundant calling than before at the following two place. > > I think change dsb(sy) to > + asm volatile(ALTERNATIVE("nop", "dsb sy", > \ > + ARM64_HAS_IRQ_PRIO_MASKING) \ > + : : : "memory"); \ > may be more appropriate. I'm not sure I understand what you mean. The static key defaults to false, so if pseudo_nmi is not enabled, this dsb(sy) is simply never executed. Am I missing something obvious? Thanks, M. > > Thanks, > Wei > >> >> @@ -34,14 +35,14 @@ static inline void arch_local_irq_enable(void) >> } >> >> asm volatile(ALTERNATIVE( >> - "msr daifclr, #2 // arch_local_irq_enable\n" >> - "nop", >> - __msr_s(SYS_ICC_PMR_EL1, "%0") >> - "dsb sy", >> + "msr daifclr, #2 // arch_local_irq_enable", >> + __msr_s(SYS_ICC_PMR_EL1, "%0"), >> ARM64_HAS_IRQ_PRIO_MASKING) >> : >> : "r" ((unsigned long) GIC_PRIO_IRQON) >> : "memory"); >> + >> + pmr_sync(); >> } >> >> static inline void arch_local_irq_disable(void) >> @@ -116,14 +117,14 @@ static inline unsigned long >> arch_local_irq_save(void) >> static inline void arch_local_irq_restore(unsigned long flags) >> { >> asm volatile(ALTERNATIVE( >> - "msr daif, %0\n" >> - "nop", >> - __msr_s(SYS_ICC_PMR_EL1, "%0") >> - "dsb sy", >> - ARM64_HAS_IRQ_PRIO_MASKING) >> + "msr daif, %0", >> + __msr_s(SYS_ICC_PMR_EL1, "%0"), >> + ARM64_HAS_IRQ_PRIO_MASKING) >> : >> : "r" (flags) >> : "memory"); >> + >> + pmr_sync(); >> } >> -- Jazz is not dead. It just smells funny...