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 503E7148823 for ; Mon, 13 May 2024 09:51:35 +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=1715593896; cv=none; b=OlkEgNtJ7m8pb10rtyWv86bkkey42Hca2VOkZEwmWkbMLyKMapP5CHfCM2LO5AXa/lvkV6ZCEuqjirIdurgguTEXm+h2TDQvQfLCnPsdzwrQFiE5ZCx3mKQAa6sUgwxyCA0ZXyPlUUvCNLNiybXGyL0Q+edMORwMOc3WH6rmqPo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715593896; c=relaxed/simple; bh=jpgJyhY9oKsVgEX61QObWfa+d24BL8Mwy+huqVc2Uik=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=hxR4xYLd6wBn8ezaso4tFq7yot7HE+Twlr6DFe98i9TNhBcOEXrbRJ3dEIAHrJV3COLhS8fleAQa0lGztug6Imf4wD3QzAacO15+O8XmCJ7B73xLVGqpD1IBSWKXcUbjchP4cYQxltsj+ehqfzkimXBLm71eAPFmx/jMrkWS5m4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q9cu9Fvq; 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="q9cu9Fvq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD74CC113CC; Mon, 13 May 2024 09:51:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715593895; bh=jpgJyhY9oKsVgEX61QObWfa+d24BL8Mwy+huqVc2Uik=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=q9cu9FvqXRqSWIUt24VXYkjz+yCX3DWcwSfT3A2IRSZoLICPqZorZkbrPbEEyOLX1 nlBw7cOaPEhrEx7inpb3Xd5LQ2lz5YPuxe63/dpSvxf2NlYlUkZ3i1ju4+z+6B7mwy 37KMdQOwVvXC2QysKgAQ3gh8oJXOl9U/0N4YTQFu+uGlMNomzZrYVetlYodK9HHK5k BBS9TGd30NiMra5AQcADYoHn+3z0lsV+MLfBgTl2gTjJRKaCyl7eo/Y/qRnKGM0jAV bcC4IZR7qnysOJ+eda4IJhvYo70SPMvJotRz6EBR+C7EiWRGCsFoNoNYvFlzdup56Z FEC50zfjmDVdw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1s6SLF-00CmdW-Pd; Mon, 13 May 2024 10:51:33 +0100 Date: Mon, 13 May 2024 10:51:32 +0100 Message-ID: <86y18em44b.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Oliver Upton , Zenghui Yu , kvmarm@lists.linux.dev, 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, broonie@kernel.org, joey.gouly@arm.com, rananta@google.com, smostafa@google.com Subject: Re: [PATCH v4 01/30] KVM: arm64: Initialize the kvm host data's fpsimd_state pointer in pKVM In-Reply-To: References: <20240423150538.2103045-1-tabba@google.com> <20240423150538.2103045-2-tabba@google.com> <4ec3be32-476a-14f2-7826-2171df1c9f77@huawei.com> <86ttj6p062.wl-maz@kernel.org> 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/29.2 (aarch64-unknown-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.219.108.64 X-SA-Exim-Rcpt-To: tabba@google.com, oliver.upton@linux.dev, yuzenghui@huawei.com, kvmarm@lists.linux.dev, 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, broonie@kernel.org, joey.gouly@arm.com, rananta@google.com, smostafa@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Sun, 12 May 2024 16:46:51 +0100, Fuad Tabba wrote: >=20 > Hi Oliver >=20 > On Sat, May 11, 2024 at 7:15=E2=80=AFPM Oliver Upton wrote: > > > > On Fri, May 10, 2024 at 09:00:54AM +0100, Fuad Tabba wrote: > > > > [...] > > > > > > > For protected VMs, we don't want to lazily save/restore the host's > > > > > fpsimd state, because that could leak information to the host tha= t the > > > > > protected guest is using fpsimd. Therefore, for protected VMs, the > > > > > host fpsimd state is maintained (saved/restored) in hyp (at EL2), > > > > > without the host needing to know or do anything about it. > > > > I'm a bit confused by this statement. Isn't pKVM downstream lazily > > managing fpsimd state on behalf of the host for protected guests? IOW, > > don't we return to the host with traps enabled at EL2 and load state > > after the trap? >=20 > Sorry, I got my wires crossed between fpsimd and sve. It's the sve > state that is restored eagerly, rather than rely on the > TIF_FOREIGN_FPSTATE as in other KVM modes. >=20 > > > > But I think that's a regression from the current status. It looks l= ike > > > > now that the state is really private to EL2, nothing will restore t= he > > > > FP context on exit, while this was the case before we reworked this. > > > > > > > > It'd be good to plug this in 6.10, as this is a regression. > > > > > > You're right. I'll send a patch to fix this. > > > > I'd be fine with a hack that *eagerly* saves/restores the fpsimd state > > on every exit in protected mode for the time being. Not great, but > > obviously correct and its not like protected mode is very useful > > upstream to begin with. >=20 > I think I have a solution that would maintain the existing behavior > for non-protected VMs in protected mode, i.e., lazy handling. I just > want to tidy up the code a bit more, run it through a few more fpsimd > and sve stress tests, and send the patches. For the record, I don't think it is worth special-casing non-protected VMs under pKVM. If eager save/restore is what pKVM needs to ensure protection, then this should equally apply to non-protected VMs. Having a single behaviour for a given host mode is hugely beneficial from a maintenance PoV. What *could* be done as an optimisation is to make the restore lazy for *everything* by trapping the host access to the FP state (similar to what we do for guests, funnily enough). But I see this only as an optimisation, not as a functional requirement. Thanks, M. --=20 Without deviation from the norm, progress is not possible.