From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A7EEFC1D for ; Mon, 20 May 2024 08:11:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716192676; cv=none; b=PORZwUFD9Xg9Ik3nTtDu5ABP4mQWdPJ6/CWW6AT+YAH9MT4AeGTp4uy45Iluud2dsLw930CgJq4Yju5YHcMnumBQrycwSIKweeKELJ4TqwIsV86TfXIxk6ehNbDk1caabfuyVhqUO40YXEZ0dh/rRLm3njXQFpALk4+71CwQo14= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716192676; c=relaxed/simple; bh=uPPCsyI8YJiboMyHupS/vpfh1xSOqnBzR4kN1jhF1/8=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=jvyUyyHNi6t01E3jekncI1Mx96k8E0sYHgJybZzCmVGfO26pirKSvljHnl9qB6nftUK81VUGbqIqrnxYA41y+oZM2ew0qJUlAAS7DLhn1jfw+/VhOJ3e21/D1DE3zu+J2uslp9B/V0nnG1Ph1UYbk94pLeKALZpKfdhJi72K4Vc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KYENnl1Y; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KYENnl1Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F032BC2BD10; Mon, 20 May 2024 08:11:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716192676; bh=uPPCsyI8YJiboMyHupS/vpfh1xSOqnBzR4kN1jhF1/8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KYENnl1YIuSscSWJ96A7LacKNrH/NOeC/G/LSD+3zZ3jDHnk0TwHNztbuO6d/XHh1 xTtUQrwYa3ATxV2rrcCJqFHS1oPyy80o3OliuMXo5VLtzMhH6aJSMQh8xjjqbCfYC+ hUp3jQDbSvSq2BKkEbG4LIAdG5bayWP+tZyuWhdWbvsj0Yu6wqL7OKl6GVgEw01Ok3 06cqHRfh06Gs0cxlXDCejtUq7p3taoXExXy5h2Qfm06HdrH3fYfO0K44kdvqD3AmQI f7VUbl6+E4My2kkOgqZ4LA/a7YM1xqSlt5O3ayw+HTZnDVfqrdFelPtqOZe8Gr2b6T Ttnth7HeUm4TQ== Received: from [185.143.37.16] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1s8y6z-00EQDc-Nd; Mon, 20 May 2024 09:11:13 +0100 Date: Mon, 20 May 2024 09:11:13 +0100 Message-ID: <87pltg3ntq.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Mark Brown , Oliver Upton , 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 In-Reply-To: References: <20240517131814.719933-1-tabba@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.143.37.16 X-SA-Exim-Rcpt-To: tabba@google.com, broonie@kernel.org, oliver.upton@linux.dev, 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 X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 20 May 2024 08:35:47 +0100, Fuad Tabba wrote: >=20 > Hi Oliver and Mark, >=20 > On Fri, May 17, 2024 at 7:19=E2=80=AFPM Mark Brown w= rote: > > > > On Fri, May 17, 2024 at 05:30:54PM +0000, Oliver Upton wrote: > > > > > Hmm... Is there any reason why we need to be concerned about preservi= ng > > > host SVE state? > > > > > The syscall ABI has it that only the first 128 bits of the vector > > > registers are preserved by the kernel, and I see no reason why we > > > couldn't apply a similar restriction to KVM_RUN HVCs into EL2. We'd n= eed > > > to eagerly flush the vector registers on entry to avoid disclosing gu= est > > > usage of SVE. > > > > > What you have is certainly correct, I just wonder if we're going out = of > > > our way to save/restore 0's for larger VLs. > > > > Not just larger VLs, there's also the P registers even for 128 bit SVE. > > > > I think it'd be sensible to discard. A big part of why the host ABI is > > like that is that the AAPCS makes the SVE specific state caller > > preserved on function calls, with syscalls mirroring that. This means > > that even if the kernel is using FP the HVC would need to be inline in a > > function using SVE in order to get any state that needs to be preserved > > in there, or there'd need to be some other non-AAPCS thing going on. We > > already ensure that any EL0 state is saved prior to trying to run a VM, > > I've not checked the interaction with pKVM here but if there's any > > issues I'd hope it's not too difficult to close them. >=20 > 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. >=20 > 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. >=20 > 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). If someone is desperate for lazy handling, then the lazy handling should apply to both protected and non-protected VMs so that we can actually reason about it. M. --=20 Without deviation from the norm, progress is not possible.