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 93CC22D6630; Mon, 21 Jul 2025 12:55:40 +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=1753102540; cv=none; b=FteO3ibgyCXpheyXdEUA2bjhqBXUH4QJVrKuC3QdCobHEG/8ZTzkwbnnxklmIzVmCWLjgsVcgKU3+c0Ok2oi7e9E43Kud/NXmd06ZUKF/JXzXQ7EpbWp1bROVjAiv0LFYxR54jx1UIN5PHkukI8nLYDLqmWDB/WfboSmJPNscWU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753102540; c=relaxed/simple; bh=N1lImdMNi0LkLe+iyg+EaG1byDnMalM2Uunw/8j+1FQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=dLwqN38S+xtXAfuF+d3gmJNmu6KuEv4a33OTi/5FPAVfEsYgFxcVGxbq6i1HmDg8YHirNCV/l7maLdYkWFGBhwVsAYAD3maTAOSJ5Gp7M/AOoc/wTgqGwuKqW2VvXBz6X8yaGLmWyfOpAw3lSS7PIB0r5sE0qwAd3V6n1amsg4s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bck23HC/; 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="bck23HC/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71E12C4CEED; Mon, 21 Jul 2025 12:55:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753102540; bh=N1lImdMNi0LkLe+iyg+EaG1byDnMalM2Uunw/8j+1FQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bck23HC/cMT/XHViqTB4pFBKeWj5JKEBoM3YuQGtlAaPyTrWcRx52PL19UYI3HFKb qhwZiszHf78d33M0HMhNsDZhAZAJ0NXeNI69A8++EYMsmK/kS90y1+b15ktEF3MR8O PEYvAeG6XhlyerdD+McSfBsyetfYrLhXjxFmgYi/ea5Zqx7pI+txWesnGeq96xg+de WeRG7Q5pFfdAyMZ8z1DQd+++PXZTKl/ZvgPdv3Z5K2cZVMSeAqVOQQlZUeZb6FXN8p NFT0+j9y9qhkFvVwDHm36SwRpbrAjVZDQ555DtIsF2GHUkxDgYmXUa2j3+8SaAupYa 6kzKVUtZ6R0Sw== 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 1udq3O-0000qr-3t; Mon, 21 Jul 2025 13:55:38 +0100 Date: Mon, 21 Jul 2025 13:55:37 +0100 Message-ID: <86o6td8zzq.wl-maz@kernel.org> From: Marc Zyngier To: Cornelia Huck Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Will Deacon , Catalin Marinas Subject: Re: [PATCH 6/7] KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner In-Reply-To: <87seip67xz.fsf@redhat.com> References: <20250721101955.535159-1-maz@kernel.org> <20250721101955.535159-7-maz@kernel.org> <87seip67xz.fsf@redhat.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/30.1 (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: cohuck@redhat.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, will@kernel.org, catalin.marinas@arm.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, 21 Jul 2025 13:32:08 +0100, Cornelia Huck wrote: > > On Mon, Jul 21 2025, Marc Zyngier wrote: > > > If we have RASv1p1 on the host, advertise it to the guest in the > > "canonical way", by setting ID_AA64PFR0_EL1 to V1P1, rather than > > the convoluted RAS+RAS_frac method. > > Don't the two methods have slightly different semantics with RAS == V1P1 > possibly implying FEAT_DoubleFault, and RAS+RAS_frac not? Ah, that's an interesting point -- I definitely had glanced over that. But I'm not sure a guest can actually distinguish between these two configurations, given that FEAT_DoubleFault is essentially an EL3 feature (as indicated in the RAS == V1P1 section, and further confirmed in R_GRJVN), making it invisible to the guest. FEAT_DoubleFault2 is, on the contrary, totally visible from the guest, and independent of EL3. Does this make sense to you? Thanks, M. -- Without deviation from the norm, progress is not possible.