[PATCH 00/11] KVM: arm64: nv: Align feature limitations with current state of support

[PATCH 00/11] KVM: arm64: nv: Align feature limitations with current state of support

[Oliver Upton]

There's a mix of features we currently hide for NV VMs that we actually
can already support, either because they have no impact on our NV
implementation or the feature was already implemented and someone forgot
to update the mask...

On top of that, I decided to invert our masking for several registers to
have denylist behavior. This is a better way to express things, IMO, as
the features we do not support are explicitly listed. In so doing, I
found a bug relating to FEAT_DoubleLock where we accidentally claim
support where we shouldn't as the 0 value implies the feature is
implemented.

I've made each relaxation into its own patch to capture the rationale in
the changelog but I'm also fine squashing these based on the affected
register. Features that limit our MMU implementation are deliberately
left masked, e.g. FEAT_ETS* and FEAT_nTLBPA place constraints on the
behavior of our nested MMU. Although the latter is highly unlikely to
matter.

Applies to 6.17-rc4. **NOTE** this depends on Jinqian's series to make
ID_AA64MMFR1_EL1.TWED writable [*], that should be applied before this
series.

[*]: https://lore.kernel.org/kvmarm/20250911114621.3724469-1-yangjinqian1@huawei.com/

Oliver Upton (11):
  KVM: arm64: nv: Convert masks to denylists in limit_nv_id_reg()
  KVM: arm64: nv: Don't erroneously claim FEAT_DoubleLock for NV VMs
  KVM: arm64: nv: Expose FEAT_DF2 to NV-enabled VMs
  KVM: arm64: nv: Expose FEAT_RASv1p1 via RAS_frac
  KVM: arm64: nv: Expose FEAT_ECBHB to NV-enabled VMs
  KVM: arm64: nv: Expose FEAT_AFP to NV-enabled VMs
  KVM: arm64: nv: Exclude guest's TWED configuration when TWE isn't set
  KVM: arm64: nv: Expose FEAT_TWED to NV-enabled VMs
  KVM: arm64: nv: Advertise FEAT_SpecSEI to NV-enabled VMs
  KVM: arm64: nv: Advertise FEAT_TIDCP1 to NV-enabled VMs
  KVM: arm64: nv: Expose up to FEAT_Debugv8p8 to NV-enabled VMs

 arch/arm64/kvm/hyp/vhe/switch.c |  7 +++++
 arch/arm64/kvm/nested.c         | 48 +++++++++++++++++++++------------
 arch/arm64/kvm/sys_regs.c       | 25 +++++++++++++++++
 3 files changed, 63 insertions(+), 17 deletions(-)


base-commit: b320789d6883cc00ac78ce83bccbfe7ed58afcf0
-- 
2.39.5

[PATCH 01/11] KVM: arm64: nv: Convert masks to denylists in limit_nv_id_reg()

[Oliver Upton]

Consistently use denylisting of features such that the limitations of
KVM's nested implementation are explicitly documented (rather than
implied).

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/nested.c | 47 +++++++++++++++++++++++++++++------------
 1 file changed, 33 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 77db81bae86f..53c57d105c93 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1462,9 +1462,18 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 
 	case SYS_ID_AA64PFR1_EL1:
 		/* Only support BTI, SSBS, CSV2_frac */
-		val &= (ID_AA64PFR1_EL1_BT	|
-			ID_AA64PFR1_EL1_SSBS	|
-			ID_AA64PFR1_EL1_CSV2_frac);
+		val &= ~(ID_AA64PFR1_EL1_PFAR		|
+			 ID_AA64PFR1_EL1_DF2		|
+			 ID_AA64PFR1_EL1_MTEX		|
+			 ID_AA64PFR1_EL1_THE		|
+			 ID_AA64PFR1_EL1_GCS		|
+			 ID_AA64PFR1_EL1_MTE_frac	|
+			 ID_AA64PFR1_EL1_NMI		|
+			 ID_AA64PFR1_EL1_SME		|
+			 ID_AA64PFR1_EL1_RES0		|
+			 ID_AA64PFR1_EL1_MPAM_frac	|
+			 ID_AA64PFR1_EL1_RAS_frac	|
+			 ID_AA64PFR1_EL1_MTE);
 		break;
 
 	case SYS_ID_AA64MMFR0_EL1:
@@ -1517,12 +1526,16 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 		break;
 
 	case SYS_ID_AA64MMFR1_EL1:
-		val &= (ID_AA64MMFR1_EL1_HCX	|
-			ID_AA64MMFR1_EL1_PAN	|
-			ID_AA64MMFR1_EL1_LO	|
-			ID_AA64MMFR1_EL1_HPDS	|
-			ID_AA64MMFR1_EL1_VH	|
-			ID_AA64MMFR1_EL1_VMIDBits);
+		val &= ~(ID_AA64MMFR1_EL1_ECBHB		|
+			 ID_AA64MMFR1_EL1_CMOW		|
+			 ID_AA64MMFR1_EL1_TIDCP1	|
+			 ID_AA64MMFR1_EL1_nTLBPA	|
+			 ID_AA64MMFR1_EL1_AFP		|
+			 ID_AA64MMFR1_EL1_ETS		|
+			 ID_AA64MMFR1_EL1_TWED		|
+			 ID_AA64MMFR1_EL1_XNX		|
+			 ID_AA64MMFR1_EL1_SpecSEI	|
+			 ID_AA64MMFR1_EL1_HAFDBS);
 		/* FEAT_E2H0 implies no VHE */
 		if (test_bit(KVM_ARM_VCPU_HAS_EL2_E2H0, kvm->arch.vcpu_features))
 			val &= ~ID_AA64MMFR1_EL1_VH;
@@ -1564,11 +1577,17 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 
 	case SYS_ID_AA64DFR0_EL1:
 		/* Only limited support for PMU, Debug, BPs, WPs, and HPMN0 */
-		val &= (ID_AA64DFR0_EL1_PMUVer	|
-			ID_AA64DFR0_EL1_WRPs	|
-			ID_AA64DFR0_EL1_BRPs	|
-			ID_AA64DFR0_EL1_DebugVer|
-			ID_AA64DFR0_EL1_HPMN0);
+		val &= ~(ID_AA64DFR0_EL1_ExtTrcBuff	|
+			 ID_AA64DFR0_EL1_BRBE		|
+			 ID_AA64DFR0_EL1_MTPMU		|
+			 ID_AA64DFR0_EL1_TraceBuffer	|
+			 ID_AA64DFR0_EL1_TraceFilt	|
+			 ID_AA64DFR0_EL1_DoubleLock	|
+			 ID_AA64DFR0_EL1_PMSVer		|
+			 ID_AA64DFR0_EL1_CTX_CMPs	|
+			 ID_AA64DFR0_EL1_SEBEP		|
+			 ID_AA64DFR0_EL1_PMSS		|
+			 ID_AA64DFR0_EL1_TraceVer);
 
 		/* Cap Debug to ARMv8.1 */
 		val = ID_REG_LIMIT_FIELD_ENUM(val, ID_AA64DFR0_EL1, DebugVer, VHE);
-- 
2.39.5

[PATCH 02/11] KVM: arm64: nv: Don't erroneously claim FEAT_DoubleLock for NV VMs

[Oliver Upton]

ID_AA64DFR0_EL1.DoubleLock is one of those annoying signed feature
fields where a non-negative value implies that a feature is implemented
and a negative value implies that it is not. While the intention of
masking this field was likely to hide the feature, KVM actually
advertises it, even on unsupporting hardware.

Remove FEAT_DoubleLock from the mask, making the NI value visible to the
VM. Take care to accept the old, incorrect values for this field as
we've lied to userspace.

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/nested.c   |  1 -
 arch/arm64/kvm/sys_regs.c | 25 +++++++++++++++++++++++++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 53c57d105c93..4044dc66fa39 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1582,7 +1582,6 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 			 ID_AA64DFR0_EL1_MTPMU		|
 			 ID_AA64DFR0_EL1_TraceBuffer	|
 			 ID_AA64DFR0_EL1_TraceFilt	|
-			 ID_AA64DFR0_EL1_DoubleLock	|
 			 ID_AA64DFR0_EL1_PMSVer		|
 			 ID_AA64DFR0_EL1_CTX_CMPs	|
 			 ID_AA64DFR0_EL1_SEBEP		|
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index b29f72478a50..cb7fc871c42d 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1997,6 +1997,26 @@ static u64 sanitise_id_aa64dfr0_el1(const struct kvm_vcpu *vcpu, u64 val)
 	return val;
 }
 
+/*
+ * Older versions of KVM erroneously claim support for FEAT_DoubleLock with
+ * NV-enabled VMs on unsupporting hardware. Silently ignore the incorrect
+ * value if it is consistent with the bug.
+ */
+static bool ignore_feat_doublelock(struct kvm_vcpu *vcpu, u64 val)
+{
+	u8 host, user;
+
+	if (!vcpu_has_nv(vcpu))
+		return false;
+
+	host = SYS_FIELD_GET(ID_AA64DFR0_EL1, DoubleLock,
+			     read_sanitised_ftr_reg(SYS_ID_AA64DFR0_EL1));
+	user = SYS_FIELD_GET(ID_AA64DFR0_EL1, DoubleLock, val);
+
+	return host == ID_AA64DFR0_EL1_DoubleLock_NI &&
+	       user == ID_AA64DFR0_EL1_DoubleLock_IMP;
+}
+
 static int set_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
 			       const struct sys_reg_desc *rd,
 			       u64 val)
@@ -2028,6 +2048,11 @@ static int set_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
 	if (debugver < ID_AA64DFR0_EL1_DebugVer_IMP)
 		return -EINVAL;
 
+	if (ignore_feat_doublelock(vcpu, val)) {
+		val &= ~ID_AA64DFR0_EL1_DoubleLock;
+		val |= SYS_FIELD_PREP_ENUM(ID_AA64DFR0_EL1, DoubleLock, NI);
+	}
+
 	return set_id_reg(vcpu, rd, val);
 }
 
-- 
2.39.5

[PATCH 03/11] KVM: arm64: nv: Expose FEAT_DF2 to NV-enabled VMs

[Oliver Upton]

The supporting infrastructure in KVM's abort injection code was merged a
while ago, but the author (me!) forgot to relax the NV limitation when
FEAT_DF2 got exposed to non-NV VMs. Fix it.

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/nested.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 4044dc66fa39..5e46e95e2684 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1463,7 +1463,6 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 	case SYS_ID_AA64PFR1_EL1:
 		/* Only support BTI, SSBS, CSV2_frac */
 		val &= ~(ID_AA64PFR1_EL1_PFAR		|
-			 ID_AA64PFR1_EL1_DF2		|
 			 ID_AA64PFR1_EL1_MTEX		|
 			 ID_AA64PFR1_EL1_THE		|
 			 ID_AA64PFR1_EL1_GCS		|
-- 
2.39.5

[PATCH 04/11] KVM: arm64: nv: Expose FEAT_RASv1p1 via RAS_frac

[Oliver Upton]

KVM already supports FEAT_RASv1p1 for NV-enabled VMs but only when
advertised through the canonical field. Stop masking the silly frac
field to expose the feature on systems without FEAT_DF.

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/nested.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 5e46e95e2684..35fa6e00c9be 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1471,7 +1471,6 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 			 ID_AA64PFR1_EL1_SME		|
 			 ID_AA64PFR1_EL1_RES0		|
 			 ID_AA64PFR1_EL1_MPAM_frac	|
-			 ID_AA64PFR1_EL1_RAS_frac	|
 			 ID_AA64PFR1_EL1_MTE);
 		break;
 
-- 
2.39.5

[PATCH 05/11] KVM: arm64: nv: Expose FEAT_ECBHB to NV-enabled VMs

[Oliver Upton]

The exact wording of the restrictions on branch prediction due to
FEAT_ECBHB in DDI0487L.b is as follows:

  When FEAT_ECBHB is implemented, the branch history information created
  in a context before an exception to a higher Exception level using
  AArch64 cannot be used by code before that exception to exploitatively
  control the execution of any indirect branches in code in a different
  context after the exception.

While vEL2 and EL1 are multiplexed at EL1, they exist in different
hardware-described contexts as KVM uses different stage-2 MMUs to
represent the corresponding translation regimes. Additionally, exception
entries into vEL2 always imply a hardware exception entry into literal EL2
for the emulated regime change.

Given all of this, and the fact that FEAT_ECBHB places no limitation on
the EL of the protected context after the exception, we can claim
FEAT_ECBHB on supporting hardware.

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/nested.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 35fa6e00c9be..20e7b11d5d67 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1524,8 +1524,7 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 		break;
 
 	case SYS_ID_AA64MMFR1_EL1:
-		val &= ~(ID_AA64MMFR1_EL1_ECBHB		|
-			 ID_AA64MMFR1_EL1_CMOW		|
+		val &= ~(ID_AA64MMFR1_EL1_CMOW		|
 			 ID_AA64MMFR1_EL1_TIDCP1	|
 			 ID_AA64MMFR1_EL1_nTLBPA	|
 			 ID_AA64MMFR1_EL1_AFP		|
-- 
2.39.5

[PATCH 06/11] KVM: arm64: nv: Expose FEAT_AFP to NV-enabled VMs

[Oliver Upton]

FEAT_AFP doesn't intersect with any EL2 trap behavior, expose to
NV-enabled VMs.

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/nested.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 20e7b11d5d67..4e70b4908c99 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1527,7 +1527,6 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 		val &= ~(ID_AA64MMFR1_EL1_CMOW		|
 			 ID_AA64MMFR1_EL1_TIDCP1	|
 			 ID_AA64MMFR1_EL1_nTLBPA	|
-			 ID_AA64MMFR1_EL1_AFP		|
 			 ID_AA64MMFR1_EL1_ETS		|
 			 ID_AA64MMFR1_EL1_TWED		|
 			 ID_AA64MMFR1_EL1_XNX		|
-- 
2.39.5

[PATCH 07/11] KVM: arm64: nv: Exclude guest's TWED configuration when TWE isn't set

[Oliver Upton]

Ignore the guest hypervisor's configured TWE delay if it hasn't actually
requested WFE traps. Otherwise, OR'ing these fields into the effective
HCR when the guest sets TWE is safe as KVM doesn't use FEAT_TWED and
leaves the fields initialized to 0.

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/hyp/vhe/switch.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 0998ad4a2552..9984c492305a 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -95,6 +95,13 @@ static u64 __compute_hcr(struct kvm_vcpu *vcpu)
 			/* Force NV2 in case the guest is forgetful... */
 			guest_hcr |= HCR_NV2;
 		}
+
+		/*
+		 * Exclude the guest's TWED configuration if it hasn't set TWE
+		 * to avoid potentially delaying traps for the host.
+		 */
+		if (!(guest_hcr & HCR_TWE))
+			guest_hcr &= ~(HCR_EL2_TWEDEn | HCR_EL2_TWEDEL);
 	}
 
 	BUG_ON(host_data_test_flag(VCPU_IN_HYP_CONTEXT) &&
-- 
2.39.5

[PATCH 08/11] KVM: arm64: nv: Expose FEAT_TWED to NV-enabled VMs

[Oliver Upton]

KVM now handles HCR_EL2.{TWEDEn,TWEDEL} correctly when computing the
effective HCR for a nested context. Advertise the feature.

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/nested.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 4e70b4908c99..a5e1a3de2742 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1528,7 +1528,6 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 			 ID_AA64MMFR1_EL1_TIDCP1	|
 			 ID_AA64MMFR1_EL1_nTLBPA	|
 			 ID_AA64MMFR1_EL1_ETS		|
-			 ID_AA64MMFR1_EL1_TWED		|
 			 ID_AA64MMFR1_EL1_XNX		|
 			 ID_AA64MMFR1_EL1_SpecSEI	|
 			 ID_AA64MMFR1_EL1_HAFDBS);
-- 
2.39.5

[PATCH 09/11] KVM: arm64: nv: Advertise FEAT_SpecSEI to NV-enabled VMs

[Oliver Upton]

FEAT_SpecSEI is an informational feature describing whether speculative
loads may generate SErrors. Since there are already cases where KVM
reinjects an SError into the VM it is already possible this may happen
due to a speculative load within the VM.

Stop hiding the feature from NV-enabled VMs.

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/nested.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index a5e1a3de2742..d3186f656d83 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1529,7 +1529,6 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 			 ID_AA64MMFR1_EL1_nTLBPA	|
 			 ID_AA64MMFR1_EL1_ETS		|
 			 ID_AA64MMFR1_EL1_XNX		|
-			 ID_AA64MMFR1_EL1_SpecSEI	|
 			 ID_AA64MMFR1_EL1_HAFDBS);
 		/* FEAT_E2H0 implies no VHE */
 		if (test_bit(KVM_ARM_VCPU_HAS_EL2_E2H0, kvm->arch.vcpu_features))
-- 
2.39.5

[PATCH 10/11] KVM: arm64: nv: Advertise FEAT_TIDCP1 to NV-enabled VMs

[Oliver Upton]

While KVM does not expose IMPDEF features to VMs, FEAT_TIDCP1 is an
architecturally-defined EL1 trap of a particular sysreg encoding range.
Furthermore, KVM already advertises this feature to non-NV VMs.

As there is no interaction with EL2 traps, expose the feature.

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/nested.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index d3186f656d83..65b5fbb88510 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1525,7 +1525,6 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 
 	case SYS_ID_AA64MMFR1_EL1:
 		val &= ~(ID_AA64MMFR1_EL1_CMOW		|
-			 ID_AA64MMFR1_EL1_TIDCP1	|
 			 ID_AA64MMFR1_EL1_nTLBPA	|
 			 ID_AA64MMFR1_EL1_ETS		|
 			 ID_AA64MMFR1_EL1_XNX		|
-- 
2.39.5

[PATCH 11/11] KVM: arm64: nv: Expose up to FEAT_Debugv8p8 to NV-enabled VMs

[Oliver Upton]

The changes to the debug architecture up to v8.8 are concerned with
external debug, which of course has no direct impact on VMs. Raise the
feature limit and document what's preventing us from raising it further.

Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
 arch/arm64/kvm/nested.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 65b5fbb88510..74bd5140c9a4 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1581,8 +1581,11 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 			 ID_AA64DFR0_EL1_PMSS		|
 			 ID_AA64DFR0_EL1_TraceVer);
 
-		/* Cap Debug to ARMv8.1 */
-		val = ID_REG_LIMIT_FIELD_ENUM(val, ID_AA64DFR0_EL1, DebugVer, VHE);
+		/*
+		 * FEAT_Debugv8p9 requires support for extended breakpoints /
+		 * watchpoints.
+		 */
+		val = ID_REG_LIMIT_FIELD_ENUM(val, ID_AA64DFR0_EL1, DebugVer, V8P8);
 		break;
 	}
 
-- 
2.39.5

Re: [PATCH 00/11] KVM: arm64: nv: Align feature limitations with current state of support

[Marc Zyngier]

On Fri, 12 Sep 2025 22:22:47 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> There's a mix of features we currently hide for NV VMs that we actually
> can already support, either because they have no impact on our NV
> implementation or the feature was already implemented and someone forgot
> to update the mask...
> 
> On top of that, I decided to invert our masking for several registers to
> have denylist behavior. This is a better way to express things, IMO, as
> the features we do not support are explicitly listed.

This was done for a reason: as long as NV was out of tree, it was far
easier to pick what we wanted to support, rather than playing
wack-a-mole as new features were popping up in the non-NV code.

Now that NV is in, and that NV support is part of the basic
requirements for anything that we add to KVM, it is probably the right
time to invert the logic.

> In so doing, I found a bug relating to FEAT_DoubleLock where we
> accidentally claim support where we shouldn't as the 0 value implies
> the feature is implemented.

Meh. Don't you love negative features?

> I've made each relaxation into its own patch to capture the rationale in
> the changelog but I'm also fine squashing these based on the affected
> register. Features that limit our MMU implementation are deliberately
> left masked, e.g. FEAT_ETS* and FEAT_nTLBPA place constraints on the
> behavior of our nested MMU. Although the latter is highly unlikely to
> matter.

Well, unlikely to matter for S2. For S1, this is a different story.

> Applies to 6.17-rc4. **NOTE** this depends on Jinqian's series to make
> ID_AA64MMFR1_EL1.TWED writable [*], that should be applied before this
> series.

Thanks for that. I'll have a look shortly.

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH 00/11] KVM: arm64: nv: Align feature limitations with current state of support

[Oliver Upton]

On Fri, Sep 12, 2025 at 10:43:05PM +0100, Marc Zyngier wrote:
> > In so doing, I found a bug relating to FEAT_DoubleLock where we
> > accidentally claim support where we shouldn't as the 0 value implies
> > the feature is implemented.
> 
> Meh. Don't you love negative features?

Just about as fun as negative polarity traps.

> > I've made each relaxation into its own patch to capture the rationale in
> > the changelog but I'm also fine squashing these based on the affected
> > register. Features that limit our MMU implementation are deliberately
> > left masked, e.g. FEAT_ETS* and FEAT_nTLBPA place constraints on the
> > behavior of our nested MMU. Although the latter is highly unlikely to
> > matter.
> 
> Well, unlikely to matter for S2. For S1, this is a different story.

Indeed -- just my general impression is that we shouldn't constrain
ourselves in terms of future MMU / TLB behavior at this point.

> > Applies to 6.17-rc4. **NOTE** this depends on Jinqian's series to make
> > ID_AA64MMFR1_EL1.TWED writable [*], that should be applied before this
> > series.
> 
> Thanks for that. I'll have a look shortly.

I'll also have a look at the series, need to revisit an open Q from the
last spin.

Thanks,
Oliver

Re: [PATCH 00/11] KVM: arm64: nv: Align feature limitations with current state of support

[Marc Zyngier]

On Fri, 12 Sep 2025 14:22:47 -0700, Oliver Upton wrote:
> There's a mix of features we currently hide for NV VMs that we actually
> can already support, either because they have no impact on our NV
> implementation or the feature was already implemented and someone forgot
> to update the mask...
> 
> On top of that, I decided to invert our masking for several registers to
> have denylist behavior. This is a better way to express things, IMO, as
> the features we do not support are explicitly listed. In so doing, I
> found a bug relating to FEAT_DoubleLock where we accidentally claim
> support where we shouldn't as the 0 value implies the feature is
> implemented.
> 
> [...]

Applied to next, thanks!

[01/11] KVM: arm64: nv: Convert masks to denylists in limit_nv_id_reg()
        commit: d3c35b7c57fc33ce787921e2faf84b7d58989a2a
[02/11] KVM: arm64: nv: Don't erroneously claim FEAT_DoubleLock for NV VMs
        commit: 49da9872a6a6fa943c02448eeae6db5e7f479283
[03/11] KVM: arm64: nv: Expose FEAT_DF2 to NV-enabled VMs
        commit: fac4ee7abe47a078a790ad2a9dd777257a186acc
[04/11] KVM: arm64: nv: Expose FEAT_RASv1p1 via RAS_frac
        commit: 26785cf28bb10bc94b2a52820c8ba1b3cfc534e5
[05/11] KVM: arm64: nv: Expose FEAT_ECBHB to NV-enabled VMs
        commit: 7cbdb25bed4046dacf139cce25fad9ef39a04a5f
[06/11] KVM: arm64: nv: Expose FEAT_AFP to NV-enabled VMs
        commit: 09dc6b42c62e47718ce0e94d44db7deffdc193ff
[07/11] KVM: arm64: nv: Exclude guest's TWED configuration when TWE isn't set
        commit: 05d9f3408334afb97b91dc869c658e6951c3dcb3
[08/11] KVM: arm64: nv: Expose FEAT_TWED to NV-enabled VMs
        commit: 952387c9d39998c7ba48a93aa7f8b8eb420d61dd
[09/11] KVM: arm64: nv: Advertise FEAT_SpecSEI to NV-enabled VMs
        commit: fe2c9cd439e0f84a31b3610e2530663e5d1d3fa8
[10/11] KVM: arm64: nv: Advertise FEAT_TIDCP1 to NV-enabled VMs
        commit: 6f2224ef07437116ae9c46257b323306260074d1
[11/11] KVM: arm64: nv: Expose up to FEAT_Debugv8p8 to NV-enabled VMs
        commit: b8b1d62f17d6fb323dc1f38dd7ad43a88fcd75e3

Cheers,

	M.
-- 
Without deviation from the norm, progress is not possible.