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 082161DE8B5; Mon, 21 Jul 2025 13:33:28 +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=1753104809; cv=none; b=c8DP0XVJM/NJwTmzqh1i5IHPx/dOk7OENqHDQ+fzPkn4f7xyvD9CSTsBZR+T3/fygM75SAF/xyUng9EcTwp4P0wgv9OsXwM9L1Xb3LyvmQczD0xpxi0he1rxqT8lHgnYhpf+AEW7sUzO49jePgcy66p2tri5he+dzMPJBaBPo3k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753104809; c=relaxed/simple; bh=xqTXA9MKZdUrT8GbMGDNoSR1qCHbkSRrB2BdWos/uaw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=qvS9fN8snupPM9xFeksqMqh38QvDC9swrhGKzfa7pY3Zddtm12RyrH+p7cE5xilZIwew9yvBPSxTaEwRXNNGYdyjujUnkDI4YFoHquW680jafSnrf4gpR/liN6ACEg8IqdDK4MoBtpUYcjpQdLpYZ5yJoOY+Iq7rOktgimSOYMg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aechEvHi; 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="aechEvHi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82283C4CEED; Mon, 21 Jul 2025 13:33:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753104808; bh=xqTXA9MKZdUrT8GbMGDNoSR1qCHbkSRrB2BdWos/uaw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aechEvHiZ9bmBFJLAHXPkKIgMqAhJ/+ST+KXWiY7sMskalQGQRb0BNmaLRwzl6re3 a4b2ot2kCWHlwJ8Pojj2a1tObrkyfwhwuCTwXL5cH0KanOF9ogwsSUbHTUDXG31Sf6 IyAWxltULsFH+pX9wHmOmOQH9amLDhc+J032kDg8+lxeJkEdrr1ezhTDqmNpo06Cf1 hiAk/rPQb8kv2EKlXl3qn5XAbuxZE/vjIW8RfcirmOIXoPGnU00j9F8257a0UThRsU cQ7eigJl3Yx4PSViCI012Uh9a4bPITQrJVac/IV0xGQ2t6HcnuioTIi2G4rsOKS55L Marj8sBpXUjbQ== 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 1udqdy-0001hv-81; Mon, 21 Jul 2025 14:33:26 +0100 Date: Mon, 21 Jul 2025 14:33:24 +0100 Message-ID: <86ldoh8y8r.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: <87pldt6630.fsf@redhat.com> References: <20250721101955.535159-1-maz@kernel.org> <20250721101955.535159-7-maz@kernel.org> <87seip67xz.fsf@redhat.com> <86o6td8zzq.wl-maz@kernel.org> <87pldt6630.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 14:12:19 +0100, Cornelia Huck wrote: > > On Mon, Jul 21 2025, Marc Zyngier wrote: > > > 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? > > It does; but it might make sense to add a comment explaining that. Sure thing. I'll add a sentence or three on the subject. > Userspace should hopefully be able to just map everything to RAS == V1P1 > and be done with it. Indeed, that's the intention. RAS_frac is zeroed and made non-writable. This is also consistent with RASv2, for which RAS_frac is not relevant (not that there is a plan to support RASv2 in the foreseeable future!). Thanks, M. -- Without deviation from the norm, progress is not possible.