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 E18F964F; Mon, 3 Jun 2024 12:36:57 +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=1717418218; cv=none; b=p6F7IaH/G146Bv8ZoQIuHORQiFVHvtppb/jXyf6AotlEbuI+8/vGDiru7VBzKeSosd6dGDL0CrMsluj6OM2dNoLPmWR7EunAU77E0FI2rLoCd2lXHW1tVSTYuNN82GTHJxpsKwPoFytSj9VezfNRx2wXce+bj1vlgJSF4xXj8hE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717418218; c=relaxed/simple; bh=uegJVi7CtFWNzVgquJOmWjJflTc+4Gwyb5TTiqX2kPE=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Vo5HyKk+3Ac08HvnR/vdkRFCSfoozSHDUwJBDgfVAMlXxEHJDSr7Qm0JcKiq/q7HVrDaJ4IYElYaBiKUpaIGRwyoHnYbmMmpKZXFuOVWEypTcWj9p5Bbq1yZvg/5e9+A9YQzyZwXXjgSAN/WPf1zOkCX9iRKKZAw+wbeFYzstoU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LGRN8NKl; 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="LGRN8NKl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7995BC32789; Mon, 3 Jun 2024 12:36:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717418217; bh=uegJVi7CtFWNzVgquJOmWjJflTc+4Gwyb5TTiqX2kPE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=LGRN8NKlA61GOjliX/livySD+0dxoo2oZl9oUw4b4o6ZQ3NsWgBYqGl1wOhyPobGo orDrahhwHZo98aoTx1S49mse3tCjXIsCe7iSBKNnPSKV4Ahe3iBLhahHN5/cDeBeSk lU5Mrwd9wb5B1Ji37mGqPVtj19uIO6O4CL3sYg2dtnDBbYy8ldG9r1aAJHaQgoGp8M it6NtFX1pYxPhbKhK0cf2P7f/LTCkx7OET1q9X8KwdlF7ZNwnGwHNE/uAoHX+g5PaU aIEonceqe1tEA0OmeUCGl687Q48KUzr7XiZ8IEhpj+5xgFItPiArUmq0h4t7BJ5eqq 9TS7klZoN8xiQ== 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 1sE6vn-000DuZ-8V; Mon, 03 Jun 2024 13:36:55 +0100 Date: Mon, 03 Jun 2024 13:36:54 +0100 Message-ID: <86le3mkxsp.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, James Morse , Suzuki K Poulose , Zenghui Yu , kvm@vger.kernel.org Subject: Re: [PATCH 10/11] KVM: arm64: nv: Honor guest hypervisor's FP/SVE traps in CPTR_EL2 In-Reply-To: <20240531231358.1000039-11-oliver.upton@linux.dev> References: <20240531231358.1000039-1-oliver.upton@linux.dev> <20240531231358.1000039-11-oliver.upton@linux.dev> 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: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, kvmarm@lists.linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Sat, 01 Jun 2024 00:13:57 +0100, Oliver Upton wrote: > > Start folding the guest hypervisor's FP/SVE traps into the value > programmed in hardware. Note that as of writing this is dead code, since > KVM does a full put() / load() for every nested exception boundary which > saves + flushes the FP/SVE state. > > However, this will become useful when we can keep the guest's FP/SVE > state alive across a nested exception boundary and the host no longer > needs to conservatively program traps. > > Signed-off-by: Oliver Upton > --- > arch/arm64/kvm/hyp/vhe/switch.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c > index 697253673d7b..d07b4f4be5e5 100644 > --- a/arch/arm64/kvm/hyp/vhe/switch.c > +++ b/arch/arm64/kvm/hyp/vhe/switch.c > @@ -85,6 +85,19 @@ static void __activate_cptr_traps(struct kvm_vcpu *vcpu) > __activate_traps_fpsimd32(vcpu); > } > > + /* > + * Layer the guest hypervisor's trap configuration on top of our own if > + * we're in a nested context. > + */ > + if (!vcpu_has_nv(vcpu) || is_hyp_ctxt(vcpu)) > + goto write; > + > + if (guest_hyp_fpsimd_traps_enabled(vcpu)) > + val &= ~CPACR_ELx_FPEN; > + if (guest_hyp_sve_traps_enabled(vcpu)) > + val &= ~CPACR_ELx_ZEN; I'm afraid this isn't quite right. You are clearing both FPEN (resp ZEN) bits based on any of the two bits being clear, while what we want is to actually propagate the 0 bits (and only those). What I have in my tree is something along the lines of: cptr = vcpu_sanitised_cptr_el2(vcpu); tmp = cptr & (CPACR_ELx_ZEN_MASK | CPACR_ELx_FPEN_MASK); val &= ~(tmp ^ (CPACR_ELx_ZEN_MASK | CPACR_ELx_FPEN_MASK)); which makes sure that we only clear the relevant bits. Thanks, M. -- Without deviation from the norm, progress is not possible.