[PATCH v1 00/10] KVM: arm64: Nested stage-2 walk error handling and other small fixes

[PATCH v1 00/10] KVM: arm64: Nested stage-2 walk error handling and other small fixes

[Fuad Tabba]

Hi folks,

Small KVM/arm64 fixes that came out of reviewing Karl's SMCCC filter
series [1], and it just kept growing.

The first two are WARNs that userspace or a guest can trigger: the
SMCCC filter one on an allocation failure userspace can force with a
memory cgroup limit, which Sashiko raised [2], the nested one when an
L1 guest programs an invalid VTCR_EL2. Patches 3 and 4 are the same
walk's return values. With an invalid VTCR_EL2 or a stage-2 descriptor
KVM can't read, AT S12E{0,1}{R,W} was retried forever instead of
retiring with the fault in PAR_EL1. Reporting the unreadable descriptor
as a Data Abort instead, for the stage-1 walks too, is a separate
change I'll send later. Patch 5 extends the AT selftest to cover the
SL0 case.

The three documentation patches fix identifiers in api.rst that don't
exist anywhere in the tree, and the last two fix selftest leaks.

Based on Linux 7.3-rc3 (fd73f4a665989; also applies to torvalds/master
fd179f8a05be3).

Cheers,
/fuad

[1] https://lore.kernel.org/all/20260829054856.70549-1-kmehltretter@gmail.com/
[2] https://lore.kernel.org/all/20260829055809.29AD31F000E9@smtp.kernel.org/

Fuad Tabba (10):
  KVM: arm64: Don't WARN on SMCCC filter reserved range allocation
    failure
  KVM: arm64: nv: Don't WARN on an invalid VTCR_EL2
  KVM: arm64: nv: Don't loop on AT S12E{0,1}{R,W} with an invalid
    VTCR_EL2
  KVM: arm64: nv: Return a failed stage-2 descriptor read as a fault
  KVM: arm64: selftests: Test AT S12E1R with an invalid VTCR_EL2.SL0
  Documentation: KVM: Fix the name of the SMCCC filter attribute
  Documentation: KVM: Fix the name of KVM_ARM_SET_COUNTER_OFFSET
  Documentation: KVM: Fix the name of KVM_ARM_FEATURE_ID_RANGE_IDX
  KVM: arm64: selftests: Free the VMs in smccc_filter and psci_test
  KVM: arm64: selftests: Free the thread arrays in vgic_lpi_stress

 Documentation/virt/kvm/api.rst                |  6 ++--
 arch/arm64/kvm/hypercalls.c                   |  2 +-
 arch/arm64/kvm/nested.c                       | 11 +++-----
 tools/testing/selftests/kvm/arm64/at.c        | 28 +++++++++++++++++++
 tools/testing/selftests/kvm/arm64/psci_test.c |  5 +++-
 .../selftests/kvm/arm64/smccc_filter.c        |  2 ++
 .../selftests/kvm/arm64/vgic_lpi_stress.c     |  3 ++
 7 files changed, 45 insertions(+), 12 deletions(-)


base-commit: fd73f4a6659897191fa0d40695fe370925dd3780
-- 
2.39.5

[PATCH v1 01/10] KVM: arm64: Don't WARN on SMCCC filter reserved range allocation failure

[Fuad Tabba]

The first time userspace sets an SMCCC filter, kvm_smccc_set_filter()
inserts the reserved architecture ranges into the maple tree and WARNs
if that fails. The tree is empty and config_lock is held, so the only
way it can fail is -ENOMEM. The allocation is GFP_KERNEL_ACCOUNT, so a
memory cgroup limit is enough to hit the WARN from userspace.

The WARN goes back to when the ranges were inserted at VM creation and
the error was dropped. Since commit d34b76489ea0c ("KVM: arm64: Only
insert reserved ranges when SMCCC filter is used") the tree is emptied
on failure and the error reaches userspace. Drop the WARN.

Fixes: d34b76489ea0c ("KVM: arm64: Only insert reserved ranges when SMCCC filter is used")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260829055809.29AD31F000E9@smtp.kernel.org/
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 arch/arm64/kvm/hypercalls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index b11b8821c9fbc..210a496733d0e 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -197,7 +197,7 @@ static int kvm_smccc_set_filter(struct kvm *kvm, struct kvm_smccc_filter __user
 
 	if (!kvm_smccc_filter_configured(kvm)) {
 		r = kvm_smccc_filter_insert_reserved(kvm);
-		if (WARN_ON_ONCE(r))
+		if (r)
 			goto out_unlock;
 	}
 
-- 
2.39.5

[PATCH v1 02/10] KVM: arm64: nv: Don't WARN on an invalid VTCR_EL2

[Fuad Tabba]

Before walking an L1 guest's stage-2 tables, KVM checks the starting
level in VTCR_EL2.SL0 and the IPA size from T0SZ against the granule
and PA size, and sets a stage-2 level 0 Translation fault when either
is invalid. The check also WARNs, so an L1 guest that programs an
invalid VTCR_EL2 triggers the WARN on every walk.

Drop the WARN.

Fixes: 61e30b9eef7ff ("KVM: arm64: nv: Implement nested Stage-2 page table walk logic")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 arch/arm64/kvm/nested.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 3c4fc566eafc6..98c1f8c193319 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -279,7 +279,7 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
 		return -EFAULT;
 
 	ret = check_base_s2_limits(vcpu, wi, level, input_size, stride);
-	if (WARN_ON(ret)) {
+	if (ret) {
 		out->esr = compute_fsc(0, ESR_ELx_FSC_FAULT);
 		return ret;
 	}
-- 
2.39.5

[PATCH v1 03/10] KVM: arm64: nv: Don't loop on AT S12E{0,1}{R,W} with an invalid VTCR_EL2

[Fuad Tabba]

When KVM walks an L1 guest's stage-2 tables, a positive return means
the walk faulted with the syndrome in out->esr, and a negative one
means KVM couldn't complete it and the caller has to retry. The
VTCR_EL2.T0SZ and SL0 checks return -EFAULT for what is the guest's
own misconfiguration: an invalid SL0 is a stage-2 level 0 Translation
fault (AArch64_S2InvalidSL()), and so is an out of range T0SZ that the
implementation doesn't clamp (AArch64_S2TxSZFaults()).

An L1 guest that programs either value therefore executes
AT S12E{0,1}{R,W} forever, since the AT is never retired, and on an L2
abort KVM injects the fault and then returns -EFAULT from KVM_RUN. The
T0SZ check also left the syndrome unset, so where a fault was reported
at all, on an L2 abort or in PAR_EL1 after a stage-1 AT, it was an
Address size fault.

Return 1 with a level 0 Translation fault from both checks, as the walk
does for the guest's other stage-2 faults.

Fixes: fd276e71d1e7b ("KVM: arm64: nv: Handle shadow stage 2 page faults")
Fixes: 92c6443222ca4 ("KVM: arm64: Propagate PTW errors up to AT emulation")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 arch/arm64/kvm/nested.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 98c1f8c193319..a67be19e73250 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -275,13 +275,10 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
 
 	stride = wi->pgshift - 3;
 	input_size = get_ia_size(wi);
-	if (input_size > 48 || input_size < 25)
-		return -EFAULT;
-
-	ret = check_base_s2_limits(vcpu, wi, level, input_size, stride);
-	if (ret) {
+	if (input_size > 48 || input_size < 25 ||
+	    check_base_s2_limits(vcpu, wi, level, input_size, stride)) {
 		out->esr = compute_fsc(0, ESR_ELx_FSC_FAULT);
-		return ret;
+		return 1;
 	}
 
 	base_lower_bound = 3 + input_size - ((3 - level) * stride +
-- 
2.39.5

[PATCH v1 04/10] KVM: arm64: nv: Return a failed stage-2 descriptor read as a fault

[Fuad Tabba]

When KVM walks an L1 guest's stage-2 tables and can't read a
descriptor, for example because the guest points a table at an IPA with
no memslot, it sets a synchronous external abort on the walk but
returns the -EFAULT from kvm_read_guest(). As with an invalid
VTCR_EL2, KVM then leaves AT S12E{0,1}{R,W} unretired, so the guest
retries it forever. On an L2 abort, KVM injects the abort and
returns -EFAULT from KVM_RUN.

Return 1, as the walk already does when it can't update a descriptor,
leaving -EAGAIN from a descriptor race as its only negative return.
The AT then retires with the external abort in PAR_EL1, which is what a
stage-1 walk records for a descriptor it can't read.

Fixes: fd276e71d1e7b ("KVM: arm64: nv: Handle shadow stage 2 page faults")
Fixes: 92c6443222ca4 ("KVM: arm64: Propagate PTW errors up to AT emulation")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 arch/arm64/kvm/nested.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index a67be19e73250..f9a2e50c0b567 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -304,7 +304,7 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
 		ret = read_guest_s2_desc(vcpu, paddr, &desc, wi);
 		if (ret < 0) {
 			out->esr = ESR_ELx_FSC_SEA_TTW(level);
-			return ret;
+			return 1;
 		}
 
 		new_desc = desc;
-- 
2.39.5

[PATCH v1 05/10] KVM: arm64: selftests: Test AT S12E1R with an invalid VTCR_EL2.SL0

[Fuad Tabba]

Check that AT S12E1R with SL0 set to 3 on 4K pages, an invalid starting
level without FEAT_TTST (which KVM doesn't expose to an L1 guest),
reports a stage-2 level 0 Translation fault in PAR_EL1. KVM used to
retry the AT forever instead, so without the fix the test hangs. An out
of range T0SZ isn't tested, since the architecture lets an
implementation clamp it instead.

Assisted-by: LLM
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 tools/testing/selftests/kvm/arm64/at.c | 28 ++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/tools/testing/selftests/kvm/arm64/at.c b/tools/testing/selftests/kvm/arm64/at.c
index ce5d312ef6baa..61fd217f724bd 100644
--- a/tools/testing/selftests/kvm/arm64/at.c
+++ b/tools/testing/selftests/kvm/arm64/at.c
@@ -73,12 +73,40 @@ static void test_at(bool expect_fault)
 	test_at_insn(S1E1W, expect_fault);
 }
 
+/* 4K granule with SL0 == 3 and no FEAT_TTST is a stage-2 level 0 Translation fault */
+static void test_at_s12_bad_sl0(void)
+{
+	u64 vtcr = FIELD_PREP(VTCR_EL2_SL0_MASK, 3) | FIELD_PREP(VTCR_EL2_T0SZ_MASK, 24);
+	u64 sctlr = read_sysreg_s(SYS_SCTLR_EL12);
+	u64 par;
+
+	/* Disable stage 1, so the stage-2 fault is on the output address, not a table walk */
+	write_sysreg_s(sctlr & ~SCTLR_ELx_M, SYS_SCTLR_EL12);
+	write_sysreg(vtcr, vtcr_el2);
+	sysreg_clear_set(hcr_el2, 0, HCR_EL2_VM);
+	isb();
+
+	__at(OP_AT_S12E1R, TEST_ADDR);
+	isb();
+	par = read_sysreg(par_el1);
+
+	sysreg_clear_set(hcr_el2, HCR_EL2_VM, 0);
+	write_sysreg(0, vtcr_el2);
+	write_sysreg_s(sctlr, SYS_SCTLR_EL12);
+	isb();
+
+	__GUEST_ASSERT((par & SYS_PAR_EL1_F) && (par & SYS_PAR_EL1_S) &&
+		       FIELD_GET(SYS_PAR_EL1_FST, par) == ESR_ELx_FSC_FAULT_L(0),
+		       "AT S12E1R: expected stage-2 level 0 translation fault (par: %lx)", par);
+}
+
 static void guest_code(void)
 {
 	sysreg_clear_set(tcr_el1, TCR_HA, 0);
 	isb();
 
 	test_at(true);
+	test_at_s12_bad_sl0();
 
 	if (!SYS_FIELD_GET(ID_AA64MMFR1_EL1, HAFDBS, read_sysreg(id_aa64mmfr1_el1)))
 		GUEST_DONE();
-- 
2.39.5

[PATCH v1 06/10] Documentation: KVM: Fix the name of the SMCCC filter attribute

[Fuad Tabba]

api.rst refers to the SMCCC filter as KVM_ARM_SMCCC_FILTER, a name that
exists nowhere else. The attribute is KVM_ARM_VM_SMCCC_FILTER.

Fixes: 821d935c87bc9 ("KVM: arm64: Introduce support for userspace SMCCC filtering")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 Documentation/virt/kvm/api.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index e0430cc750c9e..fabb1d4bf8f8d 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6873,7 +6873,7 @@ For arm64:
 
 SMCCC exits can be enabled depending on the configuration of the SMCCC
 filter. See the Documentation/virt/kvm/devices/vm.rst
-``KVM_ARM_SMCCC_FILTER`` for more details.
+``KVM_ARM_VM_SMCCC_FILTER`` for more details.
 
 ``nr`` contains the function ID of the guest's SMCCC call. Userspace is
 expected to use the ``KVM_GET_ONE_REG`` ioctl to retrieve the call
-- 
2.39.5

[PATCH v1 07/10] Documentation: KVM: Fix the name of KVM_ARM_SET_COUNTER_OFFSET

[Fuad Tabba]

The KVM_ARM_SET_COUNTER_OFFSET section of api.rst names the ioctl
KVM_ARM_SET_CNT_OFFSET, which doesn't exist.

Fixes: 1935d34afaebe ("KVM: arm64: Document KVM_ARM_SET_CNT_OFFSETS and co")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 Documentation/virt/kvm/api.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index fabb1d4bf8f8d..e5efdc56f3d29 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6265,7 +6265,7 @@ set to 0s by userspace.
 
 This capability indicates that userspace is able to apply a single VM-wide
 offset to both the virtual and physical counters as viewed by the guest
-using the KVM_ARM_SET_CNT_OFFSET ioctl and the following data structure:
+using the KVM_ARM_SET_COUNTER_OFFSET ioctl and the following data structure:
 
 ::
 
-- 
2.39.5

[PATCH v1 08/10] Documentation: KVM: Fix the name of KVM_ARM_FEATURE_ID_RANGE_IDX

[Fuad Tabba]

api.rst says the array KVM_ARM_GET_REG_WRITABLE_MASKS returns is
indexed by ARM64_FEATURE_ID_RANGE_IDX(), a macro that exists nowhere
else. The macro is KVM_ARM_FEATURE_ID_RANGE_IDX().

Fixes: 6656cda0f3b26 ("KVM: arm64: Document KVM_ARM_GET_REG_WRITABLE_MASKS")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 Documentation/virt/kvm/api.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index e5efdc56f3d29..58265372db165 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6337,7 +6337,7 @@ The Feature ID range is defined as the AArch64 System register space with
 op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7}, op2=={0-7}.
 
 The mask returned array pointed to by ``addr`` is indexed by the macro
-``ARM64_FEATURE_ID_RANGE_IDX(op0, op1, crn, crm, op2)``, allowing userspace
+``KVM_ARM_FEATURE_ID_RANGE_IDX(op0, op1, crn, crm, op2)``, allowing userspace
 to know what fields can be changed for the system register described by
 ``op0, op1, crn, crm, op2``. KVM rejects ID register values that describe a
 superset of the features supported by the system.
-- 
2.39.5

[PATCH v1 09/10] KVM: arm64: selftests: Free the VMs in smccc_filter and psci_test

[Fuad Tabba]

test_pad_must_be_zero() and host_test_system_off2() create a VM and
never free it, unlike every other test in their files. Free them.

Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 tools/testing/selftests/kvm/arm64/psci_test.c    | 5 ++++-
 tools/testing/selftests/kvm/arm64/smccc_filter.c | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kvm/arm64/psci_test.c b/tools/testing/selftests/kvm/arm64/psci_test.c
index e775faf208680..7feb7394fe110 100644
--- a/tools/testing/selftests/kvm/arm64/psci_test.c
+++ b/tools/testing/selftests/kvm/arm64/psci_test.c
@@ -239,9 +239,10 @@ static void host_test_system_off2(void)
 	u64 psci_version = 0;
 	int nr_shutdowns = 0;
 	struct kvm_run *run;
+	struct kvm_vm *vm;
 	struct ucall uc;
 
-	setup_vm(guest_test_system_off2, &source, &target);
+	vm = setup_vm(guest_test_system_off2, &source, &target);
 
 	psci_version = vcpu_get_reg(target, KVM_REG_ARM_PSCI_VERSION);
 
@@ -276,6 +277,8 @@ static void host_test_system_off2(void)
 
 	TEST_ASSERT(get_ucall(source, &uc) == UCALL_DONE, "Guest did not exit cleanly");
 	TEST_ASSERT(nr_shutdowns == 2, "Two shutdown events were expected, but saw %d", nr_shutdowns);
+
+	kvm_vm_free(vm);
 }
 
 int main(void)
diff --git a/tools/testing/selftests/kvm/arm64/smccc_filter.c b/tools/testing/selftests/kvm/arm64/smccc_filter.c
index 21e41880261b4..d5e4ba074a5c6 100644
--- a/tools/testing/selftests/kvm/arm64/smccc_filter.c
+++ b/tools/testing/selftests/kvm/arm64/smccc_filter.c
@@ -105,6 +105,8 @@ static void test_pad_must_be_zero(void)
 				  KVM_ARM_VM_SMCCC_FILTER, &filter);
 	TEST_ASSERT(r < 0 && errno == EINVAL,
 		    "Setting filter with nonzero padding should return EINVAL");
+
+	kvm_vm_free(vm);
 }
 
 /* Ensure that userspace cannot filter the Arm Architecture SMCCC range */
-- 
2.39.5

[PATCH v1 10/10] KVM: arm64: selftests: Free the thread arrays in vgic_lpi_stress

[Fuad Tabba]

run_test() allocates the vCPU and LPI thread arrays and never frees
them, while destroy_vm() frees the rest of the test's allocations. Free
them once the threads have been joined.

Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 tools/testing/selftests/kvm/arm64/vgic_lpi_stress.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/testing/selftests/kvm/arm64/vgic_lpi_stress.c b/tools/testing/selftests/kvm/arm64/vgic_lpi_stress.c
index 9a69c439a0f8f..d09db95db3bd5 100644
--- a/tools/testing/selftests/kvm/arm64/vgic_lpi_stress.c
+++ b/tools/testing/selftests/kvm/arm64/vgic_lpi_stress.c
@@ -330,6 +330,9 @@ static void run_test(void)
 		kvm_pthread_join(vcpu_threads[i], NULL);
 
 	report_stats(delta);
+
+	free(lpi_threads);
+	free(vcpu_threads);
 }
 
 static void setup_vm(void)
-- 
2.39.5

Re: [PATCH v1 01/10] KVM: arm64: Don't WARN on SMCCC filter reserved range allocation failure

[Oliver Upton]

Hi Fuad,

On Mon, Sep 28, 2026 at 04:24:58PM +0100, Fuad Tabba wrote:
> The first time userspace sets an SMCCC filter, kvm_smccc_set_filter()
> inserts the reserved architecture ranges into the maple tree and WARNs
> if that fails. The tree is empty and config_lock is held, so the only
> way it can fail is -ENOMEM. The allocation is GFP_KERNEL_ACCOUNT, so a
> memory cgroup limit is enough to hit the WARN from userspace.
> 
> The WARN goes back to when the ranges were inserted at VM creation and
> the error was dropped. Since commit d34b76489ea0c ("KVM: arm64: Only
> insert reserved ranges when SMCCC filter is used") the tree is emptied
> on failure and the error reaches userspace. Drop the WARN.

Eh, the warn is still useful. You could potentially add a check for
-ENOMEM but any other return value is a sign of something wrong in
KVM.

Thanks,
Oliver

Re: [PATCH v1 00/10] KVM: arm64: Nested stage-2 walk error handling and other small fixes

[Marc Zyngier]

On Mon, 28 Sep 2026 16:24:57 +0100,
Fuad Tabba <fuad.tabba@linux.dev> wrote:
> 
> Hi folks,
> 
> Small KVM/arm64 fixes that came out of reviewing Karl's SMCCC filter
> series [1], and it just kept growing.
> 
> The first two are WARNs that userspace or a guest can trigger: the
> SMCCC filter one on an allocation failure userspace can force with a
> memory cgroup limit, which Sashiko raised [2], the nested one when an
> L1 guest programs an invalid VTCR_EL2. Patches 3 and 4 are the same
> walk's return values. With an invalid VTCR_EL2 or a stage-2 descriptor
> KVM can't read, AT S12E{0,1}{R,W} was retried forever instead of
> retiring with the fault in PAR_EL1. Reporting the unreadable descriptor
> as a Data Abort instead, for the stage-1 walks too, is a separate
> change I'll send later.

Why later?

> Patch 5 extends the AT selftest to cover the
> SL0 case.
> 
> The three documentation patches fix identifiers in api.rst that don't
> exist anywhere in the tree, and the last two fix selftest leaks.

<rant>
What is this series about? Suppressing spurious warnings? Fixing the
PTWs?  Fixing the documentation for something totally unrelated?
Random selftest maintenance?

To give you an idea, here's what my -next branch looks like:

maz@valley-girl:~/hot-poop/arm-platforms$ git log --oneline --merges v7.3-rc3..kvmarm-master/next
5c49bb52faf38 Merge branch kvm-arm64/misc-7.4 into kvmarm-master/next
c345ec7f39efd Merge branch kvm-arm64/pre-faulting into kvmarm-master/next
2716832906bd9 Merge branch kvm-arm64/s2-rmap into kvmarm-master/next
edeb68e3d4e0c Merge tag 'kvmarm-fixes-7.3-1' into kvm-arm64/s2-rmap
ede721366f1bf Merge branch kvm-arm64/gicv5-7.4 into kvmarm-master/next
062cbcbae3e00 Merge branch kvm-arm64/gicv5-7.4 into kvmarm-master/next
928737a70c491 Merge branch kvm-arm64/hyp-type-checking-7.4 into kvmarm-master/next
1f99916b2a3d7 Merge branch kvm-arm64/selftests-7.4 into kvmarm-master/next
a8f9576fa8466 Merge branch kvm-arm64/doc-7.4 into kvmarm-master/next
7413af8a61612 Merge branch kvm-arm64/ffa-7.4 into kvmarm-master/next

Where does this series fit? What is the theme? Do you really expect me
to cherry-pick one patch after the other and build 3 or 4 consistent
series out of this? Or should simply apply it as kvm-arm64/random-stuff-from-fuad-7.4?

My definition of a series is "an ordered set of changes that have a
common theme or form a progression towards a precise goal". This is
not a series, but a patch dump.
</rant>

	M.

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

Re: [PATCH v1 00/10] KVM: arm64: Nested stage-2 walk error handling and other small fixes

[Fuad Tabba]

Hi Marc,

On Mon, 28 Sep 2026 16:58:34 +0100, Marc Zyngier <maz@kernel.org> wrote:
[...]
> > retiring with the fault in PAR_EL1. Reporting the unreadable descriptor
> > as a Data Abort instead, for the stage-1 walks too, is a separate
> > change I'll send later.
>
> Why later?

The loop fix is small and stops the hang. The Data Abort change
replaces the SEA-in-PAR_EL1 reporting at the four walk sites in at.c
and nested.c and has to stop the PC advancing past the AT. I haven't
done it yet, and I didn't want to hold the hang fix for it.

[...]
> My definition of a series is "an ordered set of changes that have a
> common theme or form a progression towards a precise goal". This is
> not a series, but a patch dump.
> </rant>

Sorry about that. When you asked me a couple of weeks ago to group
related patches rather than post them one at a time, I took it past
"related" and put everything small I had into one series.

I'll split it. The nested AT walk fixes with their selftest as one
series, with the Data Abort change in it if you'd rather have them
together, the SMCCC filter WARN on its own with Oliver's change, the
three documentation fixes as one series, and the two selftest leaks as
one.

Sorry again :)

Cheers,
/fuad

Re: [PATCH v1 01/10] KVM: arm64: Don't WARN on SMCCC filter reserved range allocation failure

[Fuad Tabba]

Hi Oliver,

On Mon, 28 Sep 2026 16:54:35 +0100, Oliver Upton <oupton@kernel.org> wrote:
[...]
> Eh, the warn is still useful. You could potentially add a check for
> -ENOMEM but any other return value is a sign of something wrong in
> KVM.

Ack, I'll keep the WARN and exempt -ENOMEM in v2 (or the new series
this becomes part of).

Cheers,
/fuad

Re: [PATCH v1 04/10] KVM: arm64: nv: Return a failed stage-2 descriptor read as a fault

[Oliver Upton]

On Mon, Sep 28, 2026 at 04:25:01PM +0100, Fuad Tabba wrote:
> When KVM walks an L1 guest's stage-2 tables and can't read a
> descriptor, for example because the guest points a table at an IPA with
> no memslot, it sets a synchronous external abort on the walk but
> returns the -EFAULT from kvm_read_guest(). As with an invalid
> VTCR_EL2, KVM then leaves AT S12E{0,1}{R,W} unretired, so the guest
> retries it forever. On an L2 abort, KVM injects the abort and
> returns -EFAULT from KVM_RUN.
> 
> Return 1, as the walk already does when it can't update a descriptor,
> leaving -EAGAIN from a descriptor race as its only negative return.
> The AT then retires with the external abort in PAR_EL1, which is what a
> stage-1 walk records for a descriptor it can't read.
> 
> Fixes: fd276e71d1e7b ("KVM: arm64: nv: Handle shadow stage 2 page faults")
> Fixes: 92c6443222ca4 ("KVM: arm64: Propagate PTW errors up to AT emulation")
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> ---
>  arch/arm64/kvm/nested.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index a67be19e73250..f9a2e50c0b567 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -304,7 +304,7 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
>  		ret = read_guest_s2_desc(vcpu, paddr, &desc, wi);
>  		if (ret < 0) {
>  			out->esr = ESR_ELx_FSC_SEA_TTW(level);
> -			return ret;
> +			return 1;

Hmm. Rather than fixing these things individually, I'd prefer aligning return
codes between the S1 and S2 walks. I agree with the approach; negative
return codes should be reserved for host-visible failure reasons whereas
everything guest visible gets communicated through s1_walk_result /
kvm_s2_trans.

Thanks,
Oliver

Re: [PATCH v1 04/10] KVM: arm64: nv: Return a failed stage-2 descriptor read as a fault

[Fuad Tabba]

Hi Oliver,

On Mon, 28 Sep 2026 17:47:48 +0100, Oliver Upton <oupton@kernel.org> wrote:
[...]
> Hmm. Rather than fixing these things individually, I'd prefer aligning return
> codes between the S1 and S2 walks. I agree with the approach; negative
> return codes should be reserved for host-visible failure reasons whereas
> everything guest visible gets communicated through s1_walk_result /
> kvm_s2_trans.

Makes sense. I'll bring the S1 walk in line with that in the respin,
with the Data Abort change on top.

Cheers,
/fuad