Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1046389pxb; Tue, 9 Feb 2021 21:19:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJzqzyk9vq/aC3kNqhbulAjHeKzPBPoiBrQYd0gDONjU8RbIoVzu7TJ+n58ASxDew8JDJLiD X-Received: by 2002:a17:906:8591:: with SMTP id v17mr1221552ejx.30.1612934371291; Tue, 09 Feb 2021 21:19:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612934371; cv=none; d=google.com; s=arc-20160816; b=dxlr0uO7aqei3Bruvj5vBr9o2OwEbpj265VQBZ7ZAVw25qN/ZWcyKD6CnX9gIWmcAY mLTGgxYnt1f1xcnbu6Np60lfUMe6IqNoOym7iQuwgN7+y9KAcGJ+WxEVMpLX8mS+jMPK D8YIlX/iVS682FLQf9qrY8EfPeyAKS62YPXwrmSa/oFnlIjDq9HZQ6ELQWe3vQQokbRQ y7B+VclNeCaUB5778Ya39p1T/JQKspxUQliNf62N/x5S48WPY1xOqoRnnMJVSXM9krKU qUenum7k2wfba5rDp3Sop35Ua1d93QX3iOR9HXnHm+3Zh6SorV102IuU7VWUeEHFgVa6 67fA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=1N2vFHFBCa+uDoq33k3f2AwtlfUt0lXYNmusjFFc+Ew=; b=ecBu6M6KqBhXEOR9AFqvsR5WbCF5Jt9OETN70I0G8u41Ke5ANsJpPKAWiTx/OMMp4G 0QDYpeWM2VugDZI7FE5Gdvid46Hm5w2HzcD61uEBDccTuQ1rmmcLdliWxz69MNQG2mDs 7G2D7EbkqU24V7/9MAOAnlAQ8PNwYHE0shkVGELxCp99J5FY/nwgXdWDhKLooeEcCwh8 GIaeAWY4Ai8Fv/vc2egqFehDFDqdeg2aWED1qbio+whzt5rcNeLz3l0f60SoL49bRqQL Tb9F3zyhdp6lBHCVWZpCJnL0DRrJdJCAhOiRgSh03oItVRRvmjHlBL6iD23OMxtTJV4x pauQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k9si670665eje.254.2021.02.09.21.19.07; Tue, 09 Feb 2021 21:19:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231927AbhBIOvD (ORCPT + 99 others); Tue, 9 Feb 2021 09:51:03 -0500 Received: from foss.arm.com ([217.140.110.172]:52806 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232262AbhBIOu5 (ORCPT ); Tue, 9 Feb 2021 09:50:57 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B9B54101E; Tue, 9 Feb 2021 06:50:11 -0800 (PST) Received: from [10.37.8.18] (unknown [10.37.8.18]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C0F223F73D; Tue, 9 Feb 2021 06:50:09 -0800 (PST) Subject: Re: [PATCH v12 6/7] arm64: mte: Save/Restore TFSR_EL1 during suspend To: Lorenzo Pieralisi , Catalin Marinas Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Andrew Morton , Will Deacon , Dmitry Vyukov , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Branislav Rankov , Andrey Konovalov References: <20210208165617.9977-1-vincenzo.frascino@arm.com> <20210208165617.9977-7-vincenzo.frascino@arm.com> <20210209115533.GE1435@arm.com> <20210209143328.GA27791@e121166-lin.cambridge.arm.com> From: Vincenzo Frascino Message-ID: <2a551330-111b-4cb4-51d1-190f2c6d8493@arm.com> Date: Tue, 9 Feb 2021 14:54:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210209143328.GA27791@e121166-lin.cambridge.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/9/21 2:33 PM, Lorenzo Pieralisi wrote: >> Do we need a similar fix for TFSRE0_EL1? We get away with this if >> suspend is only entered on the idle (kernel) thread but I recall we >> could also enter suspend on behalf of a user process (I may be wrong >> though). > Yes, when we suspend the machine to RAM, we execute suspend on behalf > on a userspace process (but that's only running on 1 cpu, the others > are hotplugged out). > > IIUC (and that's an if) TFSRE0_EL1 is checked on kernel entry so I don't > think there is a need to save/restore it (just reset it on suspend > exit). > > TFSR_EL1, I don't see a point in saving/restoring it (it is a bit > per-CPU AFAICS) either, IMO we should "check" it on suspend (if it is > possible in that context) and reset it on resume. > > I don't think though you can "check" with IRQs disabled so I suspect > that TFSR_EL1 has to be saved/restored (which means that there is a > black out period where we run kernel code without being able to detect > faults but there is no solution to that other than delaying saving the > value to just before calling into PSCI). Likewise on resume from low > power. > Ok, based on what you are saying it seems that the most viable solution here is to save and restore TFSR_EL1. I will update my code accordingly. > Thanks, > Lorenzo > -- Regards, Vincenzo