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 97FA5C25B78 for ; Tue, 4 Jun 2024 19:18:05 +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=lFShWShgw3YdMpHvDKYU3prwuAaXA99g3XQz+VZvLbc=; b=E2n8OuLJgMnEg0 7jPESslsyxCM2jkzR349CyZLl60L6eGBm9zdyj0w1zkr5dFRx9rLcnW3TN0vsyo1JUDNoSK08RVaN 318H16GIt4MYU6qJ94oL+PUua53hnSLr8fl8Bxlk4ZTxmjA/eniIJ2cHY+IrS8mLafT4lTqavD2YL euIpA1z8cTlEc513dppLms22Ro/aXyhnhXI5w6l8dKcPndA/vnIZ+eoL6/H0Dg+WU2JewYPyzG/RL 9StkCvRGvRXOaHslrGo4QtshRQAbLlCWqNemgAoxIqXw59+mFkXSD55n5GFmYFiJl6bflqJ5MG35m kdpH71os+94Ef6qvA7mg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEZfO-00000003ZK5-0Tim; Tue, 04 Jun 2024 19:17:54 +0000 Received: from out-171.mta0.migadu.com ([91.218.175.171]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEZfK-00000003ZI2-3SHx for linux-arm-kernel@lists.infradead.org; Tue, 04 Jun 2024 19:17:52 +0000 X-Envelope-To: broonie@kernel.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1717528667; 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=nZG8z3Pz30/HG+CdbBQquLuRRuC2lKE2oX6hSJa2byY=; b=XRYRl1tQjiEWpAEy4yfhRu68yQvlO6M4RRLsRJNr0eOvOvyihYYGmh2i7UG2GjGxHwAN+Q Be/6+g3n+rSrRAXBPqIOsAgjN20rCOs7SIuzVAMj2u27mVUvtinb4WCQslkAZ62lPcKNM6 W9zJZyqEFvL6zzB1ctSqXV5udBm+CCk= X-Envelope-To: maz@kernel.org X-Envelope-To: james.morse@arm.com X-Envelope-To: suzuki.poulose@arm.com X-Envelope-To: catalin.marinas@arm.com X-Envelope-To: will@kernel.org X-Envelope-To: tabba@google.com X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: kvmarm@lists.linux.dev X-Envelope-To: linux-kernel@vger.kernel.org Date: Tue, 4 Jun 2024 12:17:41 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Mark Brown Cc: Marc Zyngier , James Morse , Suzuki K Poulose , Catalin Marinas , Will Deacon , Fuad Tabba , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Fix confusion in documentation for pKVM SME assert Message-ID: References: <20240604-kvm-arm64-sme-assert-v1-1-5d98348d00f8@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240604-kvm-arm64-sme-assert-v1-1-5d98348d00f8@kernel.org> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240604_121751_288482_8464A554 X-CRM114-Status: GOOD ( 25.96 ) 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 Hi, On Tue, Jun 04, 2024 at 07:47:01PM +0100, Mark Brown wrote: > As raised in the review comments for the original patch the assert and > comment added in afb91f5f8ad7 ("KVM: arm64: Ensure that SME controls are > disabled in protected mode") are bogus. The comments says that we check > that we do not have SME enabled for a pKVM guest but the assert actually > checks to see if the host has anything set in SVCR which is unrelated to > the guest features or state, regardless of if those guests are protected > or not. > > What I believe the check is actually intended to validate is that we do > not enter the pKVM hypervisor with SME enabled since the pKVM hypervisor > does not yet understand SME and is therefore unable to save or restore > host state with SME enabled, indeed attempting to save SVE state would > fault if streaming mode is enabled on a system without FA64 due to FFR. > Update the comment to reflect this. The added context likely isn't necessary in what winds up getting applied. Can this just directly state the WARN_ON() exists b/c the protected mode hypervisor doesn't know how to manage SME state? > Fixes: afb91f5f8ad7 ("KVM: arm64: Ensure that SME controls are disabled in protected mode") > Signed-off-by: Mark Brown > --- > arch/arm64/kvm/fpsimd.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c > index 521b32868d0d..f720ba47b85c 100644 > --- a/arch/arm64/kvm/fpsimd.c > +++ b/arch/arm64/kvm/fpsimd.c > @@ -92,8 +92,9 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu) > } > > /* > - * If normal guests gain SME support, maintain this behavior for pKVM > - * guests, which don't support SME. > + * The pKVM hypervisor does not yet understand how to save or > + * restore SME state for the host so double check that if we > + * are running with pKVM we have disabled SME. > */ > WARN_ON(is_protected_kvm_enabled() && system_supports_sme() && > read_sysreg_s(SYS_SVCR)); While we're here, this should be WARN_ON_ONCE() or WARN_RATELIMIT() if we _really_ want some spam. But a single WARN ought to be enough. It'd be a good idea to also document why we're testing for SME state twice on the KVM_RUN path, as any WARN() in the hyp code is currently fatal. I'm guessing Fuad meant to have a non-fatal way of getting some debug information out. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel