From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97CFDC2D0E4 for ; Tue, 17 Nov 2020 10:45:41 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1FA72222E9 for ; Tue, 17 Nov 2020 10:45:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lxpEII17" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1FA72222E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bYwXzd0pCfUkjDNLhgekDCoIdKNEXCYAVG1qTTffLh0=; b=lxpEII17z0bo/6r0+rcXIyWzh +gvQIAcL2PPG1YAWhSWL4QJDG9iBBpgPdw2noqh4z345iwWx1T/Hs3QTKjXA9ocCahIE0dbtTj2mq pvWQHzmhaOYgbMGaw4Ihi/HXnVnPhtE16uvnZ7z86lEn7MsOP7wa29N6XpRk2UDX36yuxYtNwPRb6 UrYn+N5880vNa91Qbxv63ZJT/lOp+PqcPBw/grD7vnNDpERRbuk9WhbxsvR1E6TxY+dd3g0azyjnU 0/Bhu3XoJHj3N0swy7N4C3Zpa+OjqibedXLv8MeD1uhJzXKRHSE65C2c2LcmKbC2L7nAwLyXZXLXy e5P7xiiaA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1keyTy-0002j1-IQ; Tue, 17 Nov 2020 10:45:06 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1keyTv-0002hu-RT for linux-arm-kernel@lists.infradead.org; Tue, 17 Nov 2020 10:45:04 +0000 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 5BA10D6E; Tue, 17 Nov 2020 02:45:02 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.27.161]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AF9F93F718; Tue, 17 Nov 2020 02:45:00 -0800 (PST) Date: Tue, 17 Nov 2020 10:44:54 +0000 From: Mark Rutland To: Catalin Marinas Subject: Re: [PATCHv4 14/17] arm64: uaccess: remove set_fs() Message-ID: <20201117104454.GA73209@C02TD0UTHF1T.local> References: <20201113124937.20574-1-mark.rutland@arm.com> <20201113124937.20574-15-mark.rutland@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201117_054503_979648_EFEA2A90 X-CRM114-Status: GOOD ( 14.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: james.morse@arm.com, will@kernel.org, hch@lst.de, linux-arm-kernel@lists.infradead.org, robin.murphy@arm.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 16, 2020 at 05:40:48PM +0000, Catalin Marinas wrote: > Hi Mark, > > On Fri, Nov 13, 2020 at 12:49:34PM +0000, Mark Rutland wrote: > > We no longer need to flip UAO to access kernel memory under KERNEL_DS, > > and head.S unconditionally clears UAO for all kernel configurations via > > an ERET in init_kernel_el. Thus, we don't need to dynamically flip UAO, > > nor do we need to context-switch it. However, we do need to clear UAO > > (and set PAN) during SDEI entry. > > If the kernel never sets the UAO bit, why do we need to clear it during > SDEI entry? The fear was taking an SDEI event from a VM which had UAO set, with the SDEI FW not clearing UAO. That might not happen in practice because while the spec implies that could happen, TF-A currently generates a new PSTATE from scratch, and going forward the spec will be aligned with regular exception entry rules for PSTATE (so UAO will be cleared automatically). So we can probably drop the clearing of UAO if you prefer. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel