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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 F23ECC04FFE for ; Mon, 20 May 2024 17:38:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=YTUItDgAgJAuuceO6vKy6rHM+dPmLU6IQ3EhC/jz/vw=; b=Cpgb3y4DRQmPkY 26M4DPwwerwaDbdJAME1mykPKdv1J13wjGwfx/bT90pJlLzPrWclVWRHcF+8krB0YjFs68jrK0lKC m7Ev0BHcOHG//u08FxA39MNOjIMgko6STXSqGOpHxt0Wjn6JPK+Fp6tcSEHbLImKshv2w1tzPGQy2 2lbIC4o1zBkyENZMAeFj7Lafv3vbXDEa7zWH6COdtiugbIgxk02UnGm2gd1IfHTKciWHWaYaN4MdE Ln07YjyZfu+3ObGQD8RtI9cnMDYZs4X4zSIDVTsvwjno3dXl+iM8vuoOh8CIIRKx3T7KukEkulUcj tWr74zGOZv9CJRb6T8yw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s96xQ-0000000F9mj-1Zbv; Mon, 20 May 2024 17:37:56 +0000 Received: from out-188.mta1.migadu.com ([2001:41d0:203:375::bc]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s96xM-0000000F9ju-3McC for linux-arm-kernel@lists.infradead.org; Mon, 20 May 2024 17:37:54 +0000 X-Envelope-To: maz@kernel.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1716226662; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0UFDFH5b5m6TrAVtyz9w4Ybcvme8O+mFn9zOakWTzAU=; b=cs0JNGpPvpaHu+UOguOadWwNyzBKIoYjEUVvcDcN5xrajYxcWKWKdaLJRqhMbv8Dt035Ff 6t1mVBoLPy3nTmf7/NyBR7Wy2WZV8r0dWd/Bu18U/hsGdj8rpDnH15DIFhPlsw5LAy72vN GgQFWszBe8sK3prkNK/D7YzzZmVi89k= X-Envelope-To: tabba@google.com X-Envelope-To: broonie@kernel.org X-Envelope-To: kvmarm@lists.linux.dev X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: will@kernel.org X-Envelope-To: qperret@google.com X-Envelope-To: seanjc@google.com X-Envelope-To: alexandru.elisei@arm.com X-Envelope-To: catalin.marinas@arm.com X-Envelope-To: philmd@linaro.org X-Envelope-To: james.morse@arm.com X-Envelope-To: suzuki.poulose@arm.com X-Envelope-To: mark.rutland@arm.com X-Envelope-To: joey.gouly@arm.com X-Envelope-To: rananta@google.com X-Envelope-To: yuzenghui@huawei.com Date: Mon, 20 May 2024 17:37:36 +0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Marc Zyngier Cc: Fuad Tabba , Mark Brown , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, will@kernel.org, qperret@google.com, seanjc@google.com, alexandru.elisei@arm.com, catalin.marinas@arm.com, philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, mark.rutland@arm.com, joey.gouly@arm.com, rananta@google.com, yuzenghui@huawei.com Subject: Re: [PATCH v1 0/7] KVM: arm64: Fix handling of host fpsimd/sve state in protected mode Message-ID: References: <20240517131814.719933-1-tabba@google.com> <87pltg3ntq.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87pltg3ntq.wl-maz@kernel.org> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240520_103753_264527_5BC4297E X-CRM114-Status: GOOD ( 26.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, May 20, 2024 at 09:11:13AM +0100, Marc Zyngier wrote: > On Mon, 20 May 2024 08:35:47 +0100, Fuad Tabba wrote: > > The reason for that is that in pKVM we want to avoid leaking any > > information about protected VM activity to the host, including whether > > the VM might have performed fpsimd/sve operations. Therefore, we need > > to ensure that the host SVE state looks the same after a protected > > guest has run as it did before a protected guest has run. Wouldn't it be equally valid to just zero the state that will not be preserved regardless of whether or not the guest used fpsimd/sve? > > It would be correct to only save/restore the host's fpsimd state > > (i.e., first 128 bits of the vector registers), which is what KVM does > > in other modes. However, unless we always zero out the rest of the > > state, regardless whether the protected guest has used fpsimd/sve, > > then the host would be able to find out that the guest has in fact > > performed fpsimd/sve operations. > > > > This isn't necessary for non-protected VMs, but Marc thought that for > > now it would be better to simplify things and have pKVM behave the > > same way for both protected and non-protected VMs. As a future > > optimization for non-protected VMs, we could have them behave as VMs > > in other modes. > > And I stand by what I said. Having a hybrid mode is a maintenance > burden, and it will absolutely lead to some sort of horrible bugs (it > just take a look at the mailing list to see that we have no shortage > of bugs related to lazy FP/SVE handling). Agree, but I don't think the suggestion is in any way incompatible with eager save/restore of FP/SVE state. >From the looks of it, we're *still* adding protected-mode specialization to save/restore the host's SVE state, even though we decided in commit 8383741ab2e7 ("KVM: arm64: Get rid of host SVE tracking/saving") that this was completely unnecessary in non-protected configurations. What I'm instead suggesting is that we make it part of the __kvm_vcpu_run() API that the non-overlapping SVE state gets discarded by the callee, which would align with an expectation that the host kernel has already done this upon syscall entry. Then all of the FPSIMD/SVE save/restore logic we have in the hyp 'just works' so long as we 0 the SVE registers before loading in the host's FPSIMD state. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel