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 0DF5EC9830E for ; Sun, 27 Sep 2026 09:12:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=pE/5x1B9xdKFypHayV9J1lDYCmJcDgCZVV9ZL+4ifL4=; b=XHX8GwRG9VCLo2pJG3nDSh/8zm wpb9evlB3yjZT5tNt/nBaOP7Qbb1V5nB9ulUBKQGdJxvx3TBFDckX1r0CopZrJWTPHNAauyZ93AN0 PUtk+wTPgnomQUD6DsDClhsCVtxVY5E6ne/SJGa1hLbr0Y1ptWihqwTe8ujrJ9n71A5RR+70VbEpR EhBYWKpUhJRno6ZZs8CfVnm2OgomsOhPAdAbtxZtOZWjdhbiQFoFv2PM4CHcHZYOXFTT7CmX0B0iB 4wPJuTihzdaX2zrpp8gRIrZjHv0M10BY8o8h8p4LD3u7yXLAHqKdKTlwAQqr3QrlqLwuOz1ye1ioV bJeBnndA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xAkvT-0000000GAXS-0JVB; Sun, 27 Sep 2026 09:12:03 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xAkvS-0000000GAXM-1Dbm for linux-arm-kernel@lists.infradead.org; Sun, 27 Sep 2026 09:12:02 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 59D5343504; Sun, 27 Sep 2026 09:12:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37D981F000FF; Sun, 27 Sep 2026 09:12:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790500321; bh=pE/5x1B9xdKFypHayV9J1lDYCmJcDgCZVV9ZL+4ifL4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=RgjbsX/p/VXXRJ2MSHIB5CBHwCxGp9ORiyhpRcehI2ihGUnAn3kjILyGQwGM20sKr Ee6y1Z9RSQoEQKfw0zRw+j9U9Ezpeaz9lTGHJJ9EmoRSiVPAre7oCz8dy8VbFx5pha NGXeiX+7GlsylGrFwDVFl+9pkcIh+8hKD+FsKPbiAn3IbmNR39muGox/86gdfSCWKA AKQSHfwrJLOjFmFfAu451Sg+xM3KT07iPNxz6E3XNLxR0j8xluzuDN0zFZVmka1b7Y OGOsqpMFN8/nGlU2k1Q9JPNxOEyQ7+BfT6lL4i0+gunKOIBFSRJ2KjlF3VofwFsxj7 kmIiA7iXIEjMw== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xAkvO-0000000Dx1q-3qdl; Sun, 27 Sep 2026 09:11:59 +0000 Date: Sun, 27 Sep 2026 10:15:07 +0100 Message-ID: <87y0cn2gys.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Oliver Upton , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Joey Gouly , Suzuki K Poulose , Zenghui Yu , Steffen Eiden , Catalin Marinas , Will Deacon , Mark Rutland , Quentin Perret , Vincent Donnefort , Fuad Tabba , linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 3/4] KVM: arm64: Use the host's HCR_EL2 for non-protected VMs in pKVM In-Reply-To: <20260925090619.852995-4-fuad.tabba@linux.dev> References: <20260925090619.852995-1-fuad.tabba@linux.dev> <20260925090619.852995-4-fuad.tabba@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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) 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: fuad.tabba@linux.dev, oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, seiden@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, qperret@google.com, vdonnefort@google.com, tabba@google.com, linux-kernel@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 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 25 Sep 2026 10:06:18 +0100, Fuad Tabba wrote: > > In pKVM, a non-protected VM gets only TWI, TWE and VSE from the HCR_EL2 > the host computes for it. EL2 sets the rest in pkvm_vcpu_reset_hcr(), > which covers only part of vcpu_set_hcr(). On a CPU with MTE the VM can > then read GMID_EL1, on one without FGT it can execute a TLBI OS its ID > registers hide, and it never gets the host's TVM, VI or VF. > > Use the host's HCR_EL2 on every entry instead, except for the bits EL2 > owns. The other bits only control what the VM's own execution traps on > and which virtual exceptions are pending for it. The host computes them > from the vCPU's features, ID registers and flags, which EL2 already > takes from the host for a non-protected VM, as it takes MDCR_EL2, > HCRX_EL2 and the fine-grained traps. > > ATA, an owned bit, stays clear, as pKVM doesn't support MTE for any > guest. TID2 and TID4 move to pvm_init_traps_hcr(), since EL2 now sets > them only for a protected VM. A protected VM's HCR_EL2 is unchanged. But the host does set these bits for non-protected VMs. What is going to honor these traps? No mention of why you are adding HCR_EL2_GPF here? > > Fixes: b56680de9c648 ("KVM: arm64: Initialize trap register values in hyp in pKVM") > Signed-off-by: Fuad Tabba > --- > arch/arm64/include/asm/kvm_arm.h | 1 + > arch/arm64/kvm/hyp/include/nvhe/pkvm.h | 13 +++++++++++++ > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 ++++--- > arch/arm64/kvm/hyp/nvhe/pkvm.c | 18 ++++++++---------- > 4 files changed, 26 insertions(+), 13 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h > index 4bfbd827c5aa7..8d187650e463e 100644 > --- a/arch/arm64/include/asm/kvm_arm.h > +++ b/arch/arm64/include/asm/kvm_arm.h > @@ -30,6 +30,7 @@ > #define HCR_AMVOFFEN __HCR(AMVOFFEN) > #define HCR_TICAB __HCR(TICAB) > #define HCR_TID4 __HCR(TID4) > +#define HCR_GPF __HCR(GPF) > #define HCR_FIEN __HCR(FIEN) > #define HCR_FWB __HCR(FWB) > #define HCR_NV2 __HCR(NV2) > diff --git a/arch/arm64/kvm/hyp/include/nvhe/pkvm.h b/arch/arm64/kvm/hyp/include/nvhe/pkvm.h > index c904647d2f760..75b1122db4c91 100644 > --- a/arch/arm64/kvm/hyp/include/nvhe/pkvm.h > +++ b/arch/arm64/kvm/hyp/include/nvhe/pkvm.h > @@ -12,6 +12,19 @@ > #include > #include > > +/* > + * HCR_EL2 bits EL2 owns for a non-protected VM, whatever the host sets: those > + * that restrict the guest, configure EL2 or what it switches (E2H, RW), or > + * enable state EL2 doesn't switch or support. RES0 is included, so a bit comes > + * from the host only once arch/arm64/tools/sysreg describes it. > + */ > +#define PKVM_HCR_EL2_OWNED ((HCR_GUEST_FLAGS & ~(HCR_TWI | HCR_TWE)) | HCR_BSU | \ > + HCR_E2H | HCR_TGE | HCR_TEA | HCR_GPF | HCR_TERR | \ > + HCR_FWB | HCR_DC | HCR_ID | HCR_CD | HCR_NV | \ > + HCR_NV1 | HCR_NV2 | HCR_API | HCR_APK | HCR_ATA | \ > + HCR_DCT | HCR_FIEN | HCR_AMVOFFEN | HCR_ENSCXT | \ > + HCR_EL2_RES0) > + The name of the macro doesn't indicate that this only applies to protected VM. Also, please don't add new uses of the compat HCR macros. I really want to remove them (probably post -rc1). > /* > * Holds the relevant data for maintaining the vcpu state completely at hyp. > */ > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c > index 9a3b92e626adb..dec99d5bbee78 100644 > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c > @@ -216,6 +216,7 @@ static void sync_debug_state(struct pkvm_hyp_vcpu *hyp_vcpu) > static void flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu) > { > struct kvm_vcpu *host_vcpu = hyp_vcpu->host_vcpu; > + u64 host_hcr_mask = HCR_TWI | HCR_TWE | HCR_VSE; > > fpsimd_sve_flush(); > flush_debug_state(hyp_vcpu); > @@ -228,6 +229,7 @@ static void flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu) > if (!pkvm_hyp_vcpu_is_protected(hyp_vcpu)) { > if (vcpu_get_flag(host_vcpu, PKVM_HOST_STATE_DIRTY)) > flush_hyp_vcpu_state(hyp_vcpu); > + host_hcr_mask = ~PKVM_HCR_EL2_OWNED; This feels fragile. You start with a restrictive set (TWI, TWE, VSE), and then drop it all. At this point, I have no idea what you are letting in. It would be better to express things in a consistent way: - either the bits that are controlled by the host for either protected and non-protected guests, - or the bits that are controlled by the hypervisor for either cases. Here, you're mixing both, and that's confusing. Thanks, M. -- Jazz isn't dead. It just smells funny.