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 BC91B757EA for ; Sat, 26 Apr 2025 18:13:33 +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=1745691213; cv=none; b=Zmc48nz8TmieTMGtQiHHPpm5wB0hzbaRWPph405Zmu0YmM1L44JZQs+1W947HMJ6akjZEy9DcsjjSr66vu684WhEJLyZ78laZcLD1nFG7va5V2Lse/vzF5m63lnBMwbeOAxTB+SOFwl3F23s92ziMl4+OC8C4XYFzgOBof5nD4s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745691213; c=relaxed/simple; bh=RsOofsV613x18QvDryGpmF9JPDB5AAT2eHE5SgYik/4=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ei0J8Q7ZPcaCnTpD+cRWYL9DUJ9nv6hSrwyCZ0taPeyC7Aoje34L8ccu2dP6oq+XVBtUq/WmDaqc0gPQUVqEZ0LDOtTB3EIb9NaQf1Lcq6FABSzqNM0MxOMf/RiAD3GEeuXByWFYdsvY6FOQ/btKoYY7Yz/7qPxf507b5hEtWtQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lfO8Qw8u; 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="lfO8Qw8u" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E11BC4CEE2; Sat, 26 Apr 2025 18:13:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745691213; bh=RsOofsV613x18QvDryGpmF9JPDB5AAT2eHE5SgYik/4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lfO8Qw8uwWwgS3sjhLURcZk7YC4a076hakyri/2gKMGwKqa49LeJim1ZCTMtY9xf2 dDAD/HgSeODMIk6Ok6C+QjxHYU6jg806ULnkhzQTXOe3amTq4sMyjE9bLvzQhGcrwf drQJ1O2pb3BftisDEyyE4ngOu9hU3xVuB3y4x4+u9wFe/1gdOA2MeRiYxpWpa5RXU9 HiMm8mD0Wr6TlC8rDMn3m1hjjHZ+/Sd5KQ0kvF4xSlY3+20Zt5VZ6/nmQ7ftQk4ki3 arijG928i0j1/5vYoC6G8W6Oqu1/6Xpj3+CyA4ZiP49y4xADB0YRwHnNQKGgyidCj1 YT+y7jI4vrtuw== 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 1u8k1r-0096YO-03; Sat, 26 Apr 2025 19:13:31 +0100 Date: Sat, 26 Apr 2025 19:13:29 +0100 Message-ID: <86h62akcza.wl-maz@kernel.org> From: Marc Zyngier To: D Scott Phillips Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Mark Rutland Subject: Re: [PATCH] KVM: arm64: Force HCR_EL2.xMO to 1 at all times in VHE mode In-Reply-To: <86jz799ozo.fsf@scott-ph-mail.amperecomputing.com> References: <20250422123901.2675976-1-maz@kernel.org> <86jz799ozo.fsf@scott-ph-mail.amperecomputing.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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev 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: scott@os.amperecomputing.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, mark.rutland@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 Thu, 24 Apr 2025 23:24:59 +0100, D Scott Phillips wrote: > > Marc Zyngier writes: > > > We keep setting and clearing these bits depending on the role of > > the host kernel, mimicking what we do for nVHE. But that's actually > > pretty pointless, as we always want physical interrupts to make it > > to the host, at EL2. > > > > This has also two problems: > > > > - it prevents IRQs from being taken when these bits are cleared > > if the implementation has chosen to implement these bits as > > masks when HCR_EL2.{TGE,xMO}=={0,0} > > > > - it triggers a bad erratum on the AmpereOne HW, which catches > > fire on clearing these bits while an interrupt is being taken > > (AC03_CPU_36). > > > > Let's kill these two birds with a single stone. > > > > Reported-by: D Scott Phillips > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/kvm_arm.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h > > index 974d72b5905b8..bba4b0e930915 100644 > > --- a/arch/arm64/include/asm/kvm_arm.h > > +++ b/arch/arm64/include/asm/kvm_arm.h > > @@ -100,7 +100,7 @@ > > HCR_FMO | HCR_IMO | HCR_PTW | HCR_TID3 | HCR_TID1) > > #define HCR_HOST_NVHE_FLAGS (HCR_RW | HCR_API | HCR_APK | HCR_ATA) > > #define HCR_HOST_NVHE_PROTECTED_FLAGS (HCR_HOST_NVHE_FLAGS | HCR_TSC) > > -#define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H) > > +#define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H | HCR_AMO | HCR_IMO | HCR_FMO) > > > > #define HCRX_HOST_FLAGS (HCRX_EL2_MSCEn | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM) > > #define MPAMHCR_HOST_FLAGS 0 > > Should the xMO twiddling in __vgic_v3_get_gic_config() also get dropped > here? Ah, that old chestnut. Yeah, well spotted. It could do with some TLC. I'll do some surgery on it and post a v2. Thanks, M. -- Without deviation from the norm, progress is not possible.