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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1BFB6C433F5 for ; Wed, 4 May 2022 04:27:09 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KtP1R24N7z3bZC for ; Wed, 4 May 2022 14:27:07 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=oS+qcGOu; dkim-atps=neutral Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4KtP0g1n1Wz2xnM for ; Wed, 4 May 2022 14:26:27 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=oS+qcGOu; dkim-atps=neutral Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4KtP0b5m2Pz4xXS; Wed, 4 May 2022 14:26:23 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1651638383; bh=SHPPJp31BCnVfYWr5+Sk/nt5ENYH5SkiNTeqxa7MWkY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=oS+qcGOuDQsWFo5a/KFL13iKvl/FHlFSIqRQKe87QF1I/wEAhS4BFyWU1iX+/MWV1 1XRjbEhK9RIFQt/ElLafy/ZRjoiDjT04awFIpDkCUW8PPrmvvR6HDpOdi0lhO51K29 D3clEdBXPs3Lzv3ZXmyTGqsn9b6zZuI7/Ugor4vJRONuRUh8xNPQYM0pDnWJ+xqLm8 zOHiQ41XsurZ3lZo5onLRtJZyvJRGDH5j7psEXFXaGEwhpnTk0g7qPYfiFg2L+TedW SELKCGQxj5bluHY3tuQFqy+K6kHqCe8s1LAtTqw/HD3HL9xfQYXJy5bFilIXxT/E3N lAw47u2nlVsnQ== From: Michael Ellerman To: Fabiano Rosas , Laurent Dufour Subject: Re: [PATCH v2] powerpc/rtas: Keep MSR[RI] set when calling RTAS In-Reply-To: <87levia8wy.fsf@linux.ibm.com> References: <20220401140634.65726-1-ldufour@linux.ibm.com> <87r15aveny.fsf@mpe.ellerman.id.au> <87levia8wy.fsf@linux.ibm.com> Date: Wed, 04 May 2022 14:26:17 +1000 Message-ID: <87k0b1vs7q.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Nicholas Piggin Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Fabiano Rosas writes: > Michael Ellerman writes: >>> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S >>> index 9581906b5ee9..65cb14b56f8d 100644 >>> --- a/arch/powerpc/kernel/entry_64.S >>> +++ b/arch/powerpc/kernel/entry_64.S >>> @@ -330,22 +330,18 @@ _GLOBAL(enter_rtas) >>> clrldi r4,r4,2 /* convert to realmode address */ >>> mtlr r4 >>> >>> - li r0,0 >>> - ori r0,r0,MSR_EE|MSR_SE|MSR_BE|MSR_RI >>> - andc r0,r6,r0 >>> - >>> - li r9,1 >>> - rldicr r9,r9,MSR_SF_LG,(63-MSR_SF_LG) >>> - ori r9,r9,MSR_IR|MSR_DR|MSR_FE0|MSR_FE1|MSR_FP|MSR_RI|MSR_LE >>> - andc r6,r0,r9 >> >> One advantage of the old method is it can adapt to new MSR bits being >> set by the kernel. >> >> For example we used to use RTAS on powernv, and this code didn't need >> updating to cater to MSR_HV being set. We will probably never use RTAS >> on bare-metal again, so that's OK. >> >> But your change might break secure virtual machines, because it clears >> MSR_S whereas the old code didn't. I think SVMs did use RTAS, but I >> don't know whether it matters if it's called with MSR_S set or not? >> >> Not sure if anyone will remember, or has a working setup they can test. >> Maybe for now we just copy MSR_S from the kernel MSR the way the >> current code does. > > Would the kernel even be able to change the bit? I think only urfid can > clear MSR_S. Good point :) cheers