Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp602181imu; Thu, 13 Dec 2018 00:55:45 -0800 (PST) X-Google-Smtp-Source: AFSGD/XK9Tv5OM9UbuPOFBkbjOk8pqAbx/Pdlk8JWy8OAWPIOxAbpxgPmQquYbeRlk98LVZhxJkJ X-Received: by 2002:aa7:87ce:: with SMTP id i14mr23231295pfo.20.1544691345753; Thu, 13 Dec 2018 00:55:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544691345; cv=none; d=google.com; s=arc-20160816; b=lz1UgA4SXLvb7Q8buZSfkLMpqRqNRbtazHWFoDJy6jp/eWJ1388Mfr49eU0M1c92qP SYB1V6BeXfGpaU+Gcq2FXge73oE7spgYg5lNtvJr2GiGq5ijAXqwOAaUcWJezF9hOXXL Vbwu2MRFqzOg2biCdj/Ug9VVlKn11A7S/jzczhOoxDWA13BhnSx+SChtyyLTinamZEod 0il0nAwjGhPOV0X81WYmbkaYhYIfCVm98KwcrgO83KQRKICdeqKWLiesfKUyUQAOykNp PkccAUYsQN3P/vCtNVPyA7sp9FwfaRK6e7RP44HT/30dp9eJo7CeMi1xgmFq7T30X5Qm m0vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=blxSSRSXEa10hKBahQ4pt1/0fC27JM2kMXlbNI8N1qk=; b=0tQek4ecShB1fv0YiGJtAwywyGSR5mjCZQ4OIG3bRVPRWJ9+vMhYpILRCwLsJtVftt nXonuh9PxkocXbu/+5tsxjIoY+Yn3AgcQK7gMHK9gsMSLICYMEdeaN5GJd+/2GvhDQce qF49/rvUXt9bmeEdFWT95NMgHMrhyc7/oniOFVHoV92UuP1MXNFanb0z2a6F4i5AVzg+ PPU0N3KMMobko4FqHbG9oMLh22e0W35TzLR/J8gdmroaeSWx6E4Sou+QJfbdc03ZzfDh HrctLFbyQKMilvkNGFUlXj+ys0ezFCn1r6TOnaGtTC62A4jFT7Af8QNzz071zLaRe5DD Lfmg== 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 q9si1095926pgi.89.2018.12.13.00.55.30; Thu, 13 Dec 2018 00:55:45 -0800 (PST) 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 S1727340AbeLMIyc (ORCPT + 99 others); Thu, 13 Dec 2018 03:54:32 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:56562 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726578AbeLMIyc (ORCPT ); Thu, 13 Dec 2018 03:54:32 -0500 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 9671880D; Thu, 13 Dec 2018 00:54:31 -0800 (PST) Received: from [10.1.197.36] (e112298-lin.cambridge.arm.com [10.1.197.36]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A41E53F6A8; Thu, 13 Dec 2018 00:54:29 -0800 (PST) Subject: Re: [PATCH v7 11/25] arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking To: Ard Biesheuvel Cc: linux-arm-kernel , Linux Kernel Mailing List , Daniel Thompson , joel@joelfernandes.org, Marc Zyngier , Christoffer Dall , James Morse , Catalin Marinas , Will Deacon , Mark Rutland , oleg@redhat.com References: <1544633245-6036-1-git-send-email-julien.thierry@arm.com> <1544633245-6036-12-git-send-email-julien.thierry@arm.com> <19500d6b-62a3-21cb-9ac0-a4e5d4714a63@arm.com> From: Julien Thierry Message-ID: <31e41461-763f-aa7d-91ea-b493ede81eed@arm.com> Date: Thu, 13 Dec 2018 08:54:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/12/2018 18:10, Ard Biesheuvel wrote: > On Wed, 12 Dec 2018 at 18:59, Julien Thierry wrote: >> >> >> >> On 12/12/2018 17:27, Ard Biesheuvel wrote: >>> On Wed, 12 Dec 2018 at 17:48, Julien Thierry wrote: >>>> >>>> Instead disabling interrupts by setting the PSR.I bit, use a priority >>>> higher than the one used for interrupts to mask them via PMR. >>>> >>>> When using PMR to disable interrupts, the value of PMR will be used >>>> instead of PSR.[DAIF] for the irqflags. >>>> >>>> Signed-off-by: Julien Thierry >>>> Suggested-by: Daniel Thompson >>>> Cc: Catalin Marinas >>>> Cc: Will Deacon >>>> Cc: Ard Biesheuvel >>>> Cc: Oleg Nesterov >>>> --- >>>> arch/arm64/include/asm/efi.h | 5 +- >>>> arch/arm64/include/asm/irqflags.h | 123 +++++++++++++++++++++++++++++--------- >>>> 2 files changed, 99 insertions(+), 29 deletions(-) >>>> >>>> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h >>>> index 7ed3208..a9d3ebc 100644 >>>> --- a/arch/arm64/include/asm/efi.h >>>> +++ b/arch/arm64/include/asm/efi.h >>>> @@ -42,7 +42,10 @@ >>>> >>>> efi_status_t __efi_rt_asm_wrapper(void *, const char *, ...); >>>> >>>> -#define ARCH_EFI_IRQ_FLAGS_MASK (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT) >>>> +#define ARCH_EFI_IRQ_FLAGS_MASK \ >>>> + (system_uses_irq_prio_masking() ? \ >>>> + GIC_PRIO_IRQON : \ >>>> + (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT)) >>>> >>> >>> This mask is used to determine whether we return from a firmware call >>> with a different value for the I flag than we entered it with. So >>> instead of changing the mask, we should change the way we record DAIF, >>> given that the firmware is still going to poke the I bit if it >>> misbehaves, regardless of whether the OS happens to use priorities for >>> interrupt masking. >>> >> >> Thanks for pointing that out, so this change makes little sense... >> >> The annoying part is that the flag checking takes place in the arch >> agnostic code. >> >> Would introducing some overriddable efi_get_flags() or efi_save_flags() >> that default to local_save_flags() seem like an acceptable solution? >> >> This way I could override it for arm64 and still return the DAIF bits. >> > > I don't follow the reasoning below about irqflags exactly, but is > there any way we could simply but both PMR and DAIF in flags? We could > even update the mask here to ensure that the firmware doesn't corrupt > the PMR. > So, that was the case in my previous versions of the series, and as you said, that covered checking both DAIF bits and PMR on return from EFI services. But Catalin suggested that irqflags could just use PMR when we enable the priority masking feature. Catalin's suggestion does simplify things, except for this part. However, it doesn't seem to far-fetched to me that the architecture could have a more generic way to tell the EFI driver "this is the set of stuff that I care about and you should return from runtime services with this stuff in the same state as before" without the "set of stuff" being limited to irqflags. But maybe this would be over-engineering just to deal with my use-case... Thanks, -- Julien Thierry