[PATCH 0/4] KVM: arm64: nv: HAF fixes

[PATCH 0/4] KVM: arm64: nv: HAF fixes

[Alexandru Elisei]

Based on kvmarm's next branch.

HAF support for the software translation table walker was merged while I
was in the process of reading the patches, so instead of comments I have
these few fixes.

One thing I didn't touch is this sequence in hyp_set_prot_attr():

	if (prot & KVM_PGTABLE_PROT_X) {
		/* don't set the XN bit */
	} else {
		attr |= KVM_PTE_LEAF_ATTR_HI_S1_XN;
	}

If the caller is executing in nVHE mode, the translation regime is EL2,
which has only PrivExecute permission. Since KVM_PGTABLE_PROT_X is now the
union of PrivExecute and UnprivExecute, if the caller requests only the
UnprivExecute permission, but no PrivExecute permission, the function does
not return an error code and sets the PrivExecute permission.

Something similar happens in kvm_pgtable_hyp_pte_prot() - it will return
KVM_PGTABLE_PROT_X, which includes KVM_PGTABLE_PROT_UX (UnprivExecute) even
if the permission does not apply to the EL2 translation regime.

I have a feeling I am being too pedantic here, that's why I didn't propose
a fix. Though I thought it might be worth confirming that this isn't an
issue.

Alexandru Elisei (4):
  KVM: arm64: Document KVM_PGTABLE_PROT_{UX,PX}
  KVM: arm64: at: Use correct HA bit in TCR_EL2 when regime is EL2
  KVM: arm64: nv: Don't mask VTCR_EL2.HA if FEAT_HAFDBS is present
  KVM: arm64: at: Update AF on software walk only if VM has FEAT_HAFDBS

 arch/arm64/include/asm/kvm_arm.h     | 1 +
 arch/arm64/include/asm/kvm_pgtable.h | 4 +++-
 arch/arm64/kvm/at.c                  | 5 ++++-
 arch/arm64/kvm/nested.c              | 4 +++-
 4 files changed, 11 insertions(+), 3 deletions(-)


base-commit: 81410a2ac378414e9c60c34dac4e2c4d00969b46
-- 
2.43.0

[PATCH 1/4] KVM: arm64: Document KVM_PGTABLE_PROT_{UX,PX}

[Alexandru Elisei]

Commit 2608563b466b ("KVM: arm64: Add support for FEAT_XNX stage-2
permissions") added the KVM_PGTABLE_PROX_{UX,PX} permissions to stage 2 and
to EL2 translation regimes, but left them undocumented. Let's fix that.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
 arch/arm64/include/asm/kvm_pgtable.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index d57c12f074a4..fc02de43c68d 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -240,7 +240,9 @@ enum kvm_pgtable_stage2_flags {
 
 /**
  * enum kvm_pgtable_prot - Page-table permissions and attributes.
- * @KVM_PGTABLE_PROT_X:		Execute permission.
+ * @KVM_PGTABLE_PROT_UX:	Unprivileged execute permission.
+ * @KVM_PGTABLE_PROT_PX:	Privileged execute permission.
+ * @KVM_PGTABLE_PROT_X:		Privileged and unprivileged execute permission.
  * @KVM_PGTABLE_PROT_W:		Write permission.
  * @KVM_PGTABLE_PROT_R:		Read permission.
  * @KVM_PGTABLE_PROT_DEVICE:	Device attributes.
-- 
2.43.0

[PATCH 2/4] KVM: arm64: at: Use correct HA bit in TCR_EL2 when regime is EL2

[Alexandru Elisei]

According to ARM DDI 0487L.b, the HA bit in TCR_EL2 when the translation
regime is EL2 (or !ELIsInHost(EL2)) is bit 21, not 39.

Fixes: c59ca4b5b0c3 ("KVM: arm64: Implement HW access flag management in stage-1 SW PTW")
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
 arch/arm64/include/asm/kvm_arm.h | 1 +
 arch/arm64/kvm/at.c              | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 1da290aeedce..e500600e4b9b 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -111,6 +111,7 @@
 #define TCR_EL2_DS		(1UL << 32)
 #define TCR_EL2_RES1		((1U << 31) | (1 << 23))
 #define TCR_EL2_HPD		(1 << 24)
+#define TCR_EL2_HA		(1 << 21)
 #define TCR_EL2_TBI		(1 << 20)
 #define TCR_EL2_PS_SHIFT	16
 #define TCR_EL2_PS_MASK		(7 << TCR_EL2_PS_SHIFT)
diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index d25fef0f66e2..6d41a95f6c60 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -346,7 +346,9 @@ static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
 
 	wi->baddr &= GENMASK_ULL(wi->max_oa_bits - 1, x);
 
-	wi->ha = tcr & TCR_HA;
+	wi->ha = (wi->regime == TR_EL2 ?
+		  FIELD_GET(TCR_EL2_HA, tcr) :
+		  FIELD_GET(TCR_HA, tcr));
 
 	return 0;
 
-- 
2.43.0

[PATCH 3/4] KVM: arm64: nv: Don't mask VTCR_EL2.HA if FEAT_HAFDBS is present

[Alexandru Elisei]

Commit 39db933ba67f ("KVM: arm64: nv: Implement HW access flag management
in stage-2 SW PTW") added support for hardware updates to the access flag
to stage 2 if the feature is available to the virtual machine, but forgot
to remove the VTCR_EL2.HA bit from the res0 mask for the register. Remove
it from the mask to allow the VM to use the feature.

Fixes: 39db933ba67f ("KVM: arm64: nv: Implement HW access flag management in stage-2 SW PTW")
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
 arch/arm64/kvm/nested.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 911fc99ed99d..7a34163f6c68 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1719,7 +1719,9 @@ int kvm_init_nv_sysregs(struct kvm_vcpu *vcpu)
 	set_sysreg_masks(kvm, VTTBR_EL2, res0, res1);
 
 	/* VTCR_EL2 */
-	res0 = GENMASK(63, 32) | GENMASK(30, 20);
+	res0 = GENMASK(63, 32) | GENMASK(30, 22) | BIT(20);
+	if (!kvm_has_feat(kvm, ID_AA64MMFR1_EL1, HAFDBS, AF))
+		res0 |= VTCR_EL2_HA;
 	res1 = BIT(31);
 	set_sysreg_masks(kvm, VTCR_EL2, res0, res1);
 
-- 
2.43.0

Re: [PATCH 3/4] KVM: arm64: nv: Don't mask VTCR_EL2.HA if FEAT_HAFDBS is present

[Marc Zyngier]

On Fri, 28 Nov 2025 10:09:45 +0000,
Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> 
> Commit 39db933ba67f ("KVM: arm64: nv: Implement HW access flag management
> in stage-2 SW PTW") added support for hardware updates to the access flag
> to stage 2 if the feature is available to the virtual machine, but forgot
> to remove the VTCR_EL2.HA bit from the res0 mask for the register. Remove
> it from the mask to allow the VM to use the feature.
> 
> Fixes: 39db933ba67f ("KVM: arm64: nv: Implement HW access flag management in stage-2 SW PTW")
> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> ---
>  arch/arm64/kvm/nested.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 911fc99ed99d..7a34163f6c68 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -1719,7 +1719,9 @@ int kvm_init_nv_sysregs(struct kvm_vcpu *vcpu)
>  	set_sysreg_masks(kvm, VTTBR_EL2, res0, res1);
>  
>  	/* VTCR_EL2 */
> -	res0 = GENMASK(63, 32) | GENMASK(30, 20);
> +	res0 = GENMASK(63, 32) | GENMASK(30, 22) | BIT(20);
> +	if (!kvm_has_feat(kvm, ID_AA64MMFR1_EL1, HAFDBS, AF))
> +		res0 |= VTCR_EL2_HA;
>  	res1 = BIT(31);
>  	set_sysreg_masks(kvm, VTCR_EL2, res0, res1);
>  

The fix is correct, but I really do not want to add more of these
tedious checks, one after the other. We should fix this once and for
all by converting VTCR_EL2 to the feature dependency infrastructure
and be done with it.

I've pushed a small series at [1] that does that (very lightly
tested).

Thanks,

	M.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/vtcr

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

Re: [PATCH 3/4] KVM: arm64: nv: Don't mask VTCR_EL2.HA if FEAT_HAFDBS is present

[Oliver Upton]

On Fri, Nov 28, 2025 at 03:46:44PM +0000, Marc Zyngier wrote:
> On Fri, 28 Nov 2025 10:09:45 +0000,
> Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> > 
> > Commit 39db933ba67f ("KVM: arm64: nv: Implement HW access flag management
> > in stage-2 SW PTW") added support for hardware updates to the access flag
> > to stage 2 if the feature is available to the virtual machine, but forgot
> > to remove the VTCR_EL2.HA bit from the res0 mask for the register. Remove
> > it from the mask to allow the VM to use the feature.
> > 
> > Fixes: 39db933ba67f ("KVM: arm64: nv: Implement HW access flag management in stage-2 SW PTW")
> > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> > ---
> >  arch/arm64/kvm/nested.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index 911fc99ed99d..7a34163f6c68 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> > @@ -1719,7 +1719,9 @@ int kvm_init_nv_sysregs(struct kvm_vcpu *vcpu)
> >  	set_sysreg_masks(kvm, VTTBR_EL2, res0, res1);
> >  
> >  	/* VTCR_EL2 */
> > -	res0 = GENMASK(63, 32) | GENMASK(30, 20);
> > +	res0 = GENMASK(63, 32) | GENMASK(30, 22) | BIT(20);
> > +	if (!kvm_has_feat(kvm, ID_AA64MMFR1_EL1, HAFDBS, AF))
> > +		res0 |= VTCR_EL2_HA;
> >  	res1 = BIT(31);
> >  	set_sysreg_masks(kvm, VTCR_EL2, res0, res1);
> >  
> 
> The fix is correct, but I really do not want to add more of these
> tedious checks, one after the other. We should fix this once and for
> all by converting VTCR_EL2 to the feature dependency infrastructure
> and be done with it.
> 
> I've pushed a small series at [1] that does that (very lightly
> tested).

This looks alright to me, do you want to post it?

Thanks,
Oliver

Re: [PATCH 3/4] KVM: arm64: nv: Don't mask VTCR_EL2.HA if FEAT_HAFDBS is present

[Marc Zyngier]

On Fri, 28 Nov 2025 18:48:10 +0000,
Oliver Upton <oupton@kernel.org> wrote:
> 
> On Fri, Nov 28, 2025 at 03:46:44PM +0000, Marc Zyngier wrote:
> > On Fri, 28 Nov 2025 10:09:45 +0000,
> > Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> > > 
> > > Commit 39db933ba67f ("KVM: arm64: nv: Implement HW access flag management
> > > in stage-2 SW PTW") added support for hardware updates to the access flag
> > > to stage 2 if the feature is available to the virtual machine, but forgot
> > > to remove the VTCR_EL2.HA bit from the res0 mask for the register. Remove
> > > it from the mask to allow the VM to use the feature.
> > > 
> > > Fixes: 39db933ba67f ("KVM: arm64: nv: Implement HW access flag management in stage-2 SW PTW")
> > > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> > > ---
> > >  arch/arm64/kvm/nested.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > > index 911fc99ed99d..7a34163f6c68 100644
> > > --- a/arch/arm64/kvm/nested.c
> > > +++ b/arch/arm64/kvm/nested.c
> > > @@ -1719,7 +1719,9 @@ int kvm_init_nv_sysregs(struct kvm_vcpu *vcpu)
> > >  	set_sysreg_masks(kvm, VTTBR_EL2, res0, res1);
> > >  
> > >  	/* VTCR_EL2 */
> > > -	res0 = GENMASK(63, 32) | GENMASK(30, 20);
> > > +	res0 = GENMASK(63, 32) | GENMASK(30, 22) | BIT(20);
> > > +	if (!kvm_has_feat(kvm, ID_AA64MMFR1_EL1, HAFDBS, AF))
> > > +		res0 |= VTCR_EL2_HA;
> > >  	res1 = BIT(31);
> > >  	set_sysreg_masks(kvm, VTCR_EL2, res0, res1);
> > >  
> > 
> > The fix is correct, but I really do not want to add more of these
> > tedious checks, one after the other. We should fix this once and for
> > all by converting VTCR_EL2 to the feature dependency infrastructure
> > and be done with it.
> > 
> > I've pushed a small series at [1] that does that (very lightly
> > tested).
> 
> This looks alright to me, do you want to post it?

Still fixing some of the fallout from the sysreg conversion -- a bunch
of things that were shifted constants are now unshifted, and need to
be FIELD_PREP()'d.

I *think* I got them all now, but this is all a bit fiddly. Should the
last tests run smoothly,

Note that the TCR conversion will be even more invasive, and probably
not merge window material, so you may want to pick Alexandru's 4th
patch as well.

Thanks,

	M.

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

[PATCH 4/4] KVM: arm64: at: Update AF on software walk only if VM has FEAT_HAFDBS

[Alexandru Elisei]

A guest can write 1 to TCR_ELx.HA, making the KVM software walker update
the access flag in a table descriptor even if FEAT_HAFDBS is not present.
Avoid this by making wi->ha depend on FEAT_HAFDBS being enabled in the VM,
similar to how the software walker treats FEAT_HPDS.

This is not needed for VTCR_EL2.HA, since a guest will always write to
the in-memory copy of the register, where the HA bit is masked (set to
0) by KVM if the VM doesn't have FEAT_HAFDBS.

Fixes: c59ca4b5b0c3 ("KVM: arm64: Implement HW access flag management in stage-1 SW PTW")
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
 arch/arm64/kvm/at.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index 6d41a95f6c60..53bf70126f81 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -346,7 +346,8 @@ static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
 
 	wi->baddr &= GENMASK_ULL(wi->max_oa_bits - 1, x);
 
-	wi->ha = (wi->regime == TR_EL2 ?
+	wi->ha  = kvm_has_feat(vcpu->kvm, ID_AA64MMFR1_EL1, HAFDBS, AF);
+	wi->ha &= (wi->regime == TR_EL2 ?
 		  FIELD_GET(TCR_EL2_HA, tcr) :
 		  FIELD_GET(TCR_HA, tcr));
 
-- 
2.43.0

Re: [PATCH 4/4] KVM: arm64: at: Update AF on software walk only if VM has FEAT_HAFDBS

[Marc Zyngier]

On Fri, 28 Nov 2025 10:09:46 +0000,
Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> 
> A guest can write 1 to TCR_ELx.HA, making the KVM software walker update
> the access flag in a table descriptor even if FEAT_HAFDBS is not present.
> Avoid this by making wi->ha depend on FEAT_HAFDBS being enabled in the VM,
> similar to how the software walker treats FEAT_HPDS.
> 
> This is not needed for VTCR_EL2.HA, since a guest will always write to
> the in-memory copy of the register, where the HA bit is masked (set to
> 0) by KVM if the VM doesn't have FEAT_HAFDBS.
> 
> Fixes: c59ca4b5b0c3 ("KVM: arm64: Implement HW access flag management in stage-1 SW PTW")
> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> ---
>  arch/arm64/kvm/at.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
> index 6d41a95f6c60..53bf70126f81 100644
> --- a/arch/arm64/kvm/at.c
> +++ b/arch/arm64/kvm/at.c
> @@ -346,7 +346,8 @@ static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
>  
>  	wi->baddr &= GENMASK_ULL(wi->max_oa_bits - 1, x);
>  
> -	wi->ha = (wi->regime == TR_EL2 ?
> +	wi->ha  = kvm_has_feat(vcpu->kvm, ID_AA64MMFR1_EL1, HAFDBS, AF);
> +	wi->ha &= (wi->regime == TR_EL2 ?
>  		  FIELD_GET(TCR_EL2_HA, tcr) :
>  		  FIELD_GET(TCR_HA, tcr));

This is yet another case where we should expand the sanitisation
infrastructure to cover the TCR registers.

Thanks,

	M.

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

Re: [PATCH 0/4] KVM: arm64: nv: HAF fixes

[Oliver Upton]

On Fri, 28 Nov 2025 10:09:42 +0000, Alexandru Elisei wrote:
> Based on kvmarm's next branch.
> 
> HAF support for the software translation table walker was merged while I
> was in the process of reading the patches, so instead of comments I have
> these few fixes.
> 
> One thing I didn't touch is this sequence in hyp_set_prot_attr():
> 
> [...]

Applied to next, thanks!

[1/4] KVM: arm64: Document KVM_PGTABLE_PROT_{UX,PX}
      https://git.kernel.org/kvmarm/kvmarm/c/a3e927e1432a
[2/4] KVM: arm64: at: Use correct HA bit in TCR_EL2 when regime is EL2
      https://git.kernel.org/kvmarm/kvmarm/c/c560b0121d02

--
Best,
Oliver

Re: [PATCH 0/4] KVM: arm64: nv: HAF fixes

[Marc Zyngier]

On Fri, 28 Nov 2025 10:09:42 +0000,
Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> 
> Based on kvmarm's next branch.
> 
> HAF support for the software translation table walker was merged while I
> was in the process of reading the patches, so instead of comments I have
> these few fixes.
> 
> One thing I didn't touch is this sequence in hyp_set_prot_attr():
> 
> 	if (prot & KVM_PGTABLE_PROT_X) {
> 		/* don't set the XN bit */
> 	} else {
> 		attr |= KVM_PTE_LEAF_ATTR_HI_S1_XN;
> 	}
> 
> If the caller is executing in nVHE mode, the translation regime is EL2,
> which has only PrivExecute permission. Since KVM_PGTABLE_PROT_X is now the
> union of PrivExecute and UnprivExecute, if the caller requests only the
> UnprivExecute permission, but no PrivExecute permission, the function does
> not return an error code and sets the PrivExecute permission.

I don't think this is a huge problem *right now*, as long as we don't
have anything that looks like "hvhe hypervisor userspace" (yes, I
proposed that a while ago, and haven't completely dropped the
idea). But at the same time, the page-table code should probably be
built to the architecture and not to the use cases.

But it also outlines a rather bad bug in the hVHE case, where we set
the UXN bit instead of the PXN bit...

What I have in mind is something like this, untested. Thoughts?

	M.

diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index d57c12f074a40..48305118ba3c5 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -88,6 +88,8 @@ typedef u64 kvm_pte_t;
 #define KVM_PTE_LEAF_ATTR_HI_SW		GENMASK(58, 55)
 
 #define KVM_PTE_LEAF_ATTR_HI_S1_XN	BIT(54)
+#define KVM_PTE_LEAF_ATTR_HI_S1_UXN	BIT(54)
+#define KVM_PTE_LEAF_ATTR_HI_S1_PXN	BIT(53)
 
 #define KVM_PTE_LEAF_ATTR_HI_S2_XN	GENMASK(54, 53)
 
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index e0bd6a0172729..cbf9b6b58e284 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -330,6 +330,11 @@ struct hyp_map_data {
 	kvm_pte_t			attr;
 };
 
+static bool el2_nvhe(void)
+{
+	return !has_vhe() && !cpus_have_final_cap(ARM64_KVM_PROTECTED_MODE);
+}
+
 static int hyp_set_prot_attr(enum kvm_pgtable_prot prot, kvm_pte_t *ptep)
 {
 	bool device = prot & KVM_PGTABLE_PROT_DEVICE;
@@ -342,6 +347,9 @@ static int hyp_set_prot_attr(enum kvm_pgtable_prot prot, kvm_pte_t *ptep)
 	if (!(prot & KVM_PGTABLE_PROT_R))
 		return -EINVAL;
 
+	if (el2_nvhe())
+		prot &= ~KVM_PGTABLE_PROT_UX;
+
 	if (prot & KVM_PGTABLE_PROT_X) {
 		if (prot & KVM_PGTABLE_PROT_W)
 			return -EINVAL;
@@ -351,8 +359,16 @@ static int hyp_set_prot_attr(enum kvm_pgtable_prot prot, kvm_pte_t *ptep)
 
 		if (system_supports_bti_kernel())
 			attr |= KVM_PTE_LEAF_ATTR_HI_S1_GP;
+	}
+
+	if (el2_nvhe()) {
+		if (!(prot & KVM_PGTABLE_PROT_PX))
+			attr |= KVM_PTE_LEAF_ATTR_HI_S1_XN;
 	} else {
-		attr |= KVM_PTE_LEAF_ATTR_HI_S1_XN;
+		if (!(prot & KVM_PGTABLE_PROT_PX))
+			attr |= KVM_PTE_LEAF_ATTR_HI_S1_PXN;
+		if (!(prot & KVM_PGTABLE_PROT_UX))
+			attr |= KVM_PTE_LEAF_ATTR_HI_S1_UXN;
 	}
 
 	attr |= FIELD_PREP(KVM_PTE_LEAF_ATTR_LO_S1_AP, ap);
@@ -373,8 +389,15 @@ enum kvm_pgtable_prot kvm_pgtable_hyp_pte_prot(kvm_pte_t pte)
 	if (!kvm_pte_valid(pte))
 		return prot;
 
-	if (!(pte & KVM_PTE_LEAF_ATTR_HI_S1_XN))
-		prot |= KVM_PGTABLE_PROT_X;
+	if (el2_nvhe()) {
+		if (!(pte & KVM_PTE_LEAF_ATTR_HI_S1_XN))
+			prot |= KVM_PGTABLE_PROT_PX;
+	} else {
+		if (!(pte & KVM_PTE_LEAF_ATTR_HI_S1_PXN))
+			prot |= KVM_PGTABLE_PROT_PX;
+		if (!(pte & KVM_PTE_LEAF_ATTR_HI_S1_UXN))
+			prot |= KVM_PGTABLE_PROT_UX;
+	}
 
 	ap = FIELD_GET(KVM_PTE_LEAF_ATTR_LO_S1_AP, pte);
 	if (ap == KVM_PTE_LEAF_ATTR_LO_S1_AP_RO)

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

Re: [PATCH 0/4] KVM: arm64: nv: HAF fixes

[Marc Zyngier]

On Sun, 30 Nov 2025 13:11:57 +0000,
Marc Zyngier <maz@kernel.org> wrote:
> 
> On Fri, 28 Nov 2025 10:09:42 +0000,
> Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> > 
> > Based on kvmarm's next branch.
> > 
> > HAF support for the software translation table walker was merged while I
> > was in the process of reading the patches, so instead of comments I have
> > these few fixes.
> > 
> > One thing I didn't touch is this sequence in hyp_set_prot_attr():
> > 
> > 	if (prot & KVM_PGTABLE_PROT_X) {
> > 		/* don't set the XN bit */
> > 	} else {
> > 		attr |= KVM_PTE_LEAF_ATTR_HI_S1_XN;
> > 	}
> > 
> > If the caller is executing in nVHE mode, the translation regime is EL2,
> > which has only PrivExecute permission. Since KVM_PGTABLE_PROT_X is now the
> > union of PrivExecute and UnprivExecute, if the caller requests only the
> > UnprivExecute permission, but no PrivExecute permission, the function does
> > not return an error code and sets the PrivExecute permission.
> 
> I don't think this is a huge problem *right now*, as long as we don't
> have anything that looks like "hvhe hypervisor userspace" (yes, I
> proposed that a while ago, and haven't completely dropped the
> idea). But at the same time, the page-table code should probably be
> built to the architecture and not to the use cases.
> 
> But it also outlines a rather bad bug in the hVHE case, where we set
> the UXN bit instead of the PXN bit...
> 
> What I have in mind is something like this, untested. Thoughts?
> 
> 	M.
> 
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index d57c12f074a40..48305118ba3c5 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -88,6 +88,8 @@ typedef u64 kvm_pte_t;
>  #define KVM_PTE_LEAF_ATTR_HI_SW		GENMASK(58, 55)
>  
>  #define KVM_PTE_LEAF_ATTR_HI_S1_XN	BIT(54)
> +#define KVM_PTE_LEAF_ATTR_HI_S1_UXN	BIT(54)
> +#define KVM_PTE_LEAF_ATTR_HI_S1_PXN	BIT(53)
>  
>  #define KVM_PTE_LEAF_ATTR_HI_S2_XN	GENMASK(54, 53)
>  
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index e0bd6a0172729..cbf9b6b58e284 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -330,6 +330,11 @@ struct hyp_map_data {
>  	kvm_pte_t			attr;
>  };
>  
> +static bool el2_nvhe(void)
> +{
> +	return !has_vhe() && !cpus_have_final_cap(ARM64_KVM_PROTECTED_MODE);

Obviously, this should read ARM64_KVM_HVHE, not PROTECTED_MODE...

	M.

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