Skip to contentSkip to conversation

KVM: selftests: add powerpc support

PATCH Superseded Ritesh Harjani (IBM) 4 participants 27 messages Sep 22 – Oct 6

Subsystems (3)

v5 of 7 Superseded Latest is v7 →

lore
Share & tools
lore
#0 lore raw

v5 cover KVM: selftests: add powerpc support

Patch v4 -> v5:
==============
- Fixed the issues reported by Anushree while running on kvm on powervm (nested).
- Fixed memslot_perf_test on powerpc.

PATCH v3 -> PATCH v4:
==================
- Rebased on top of Sean's new page allocator patch series v2 [1] This allowed to drop and patch-2 since it will now come from Sean's v2.
- Addressed review comments from Sean - squashed patches 6-10 in patch-1 of this.
- Dropped patch-5 to print vcpu_id when KVM_CREATE_VCPU ioctl fails.
- Added additional patch-3 to this series to allow dirty_log_test to run on all big-endian machines.

[1]: https://lore.kernel.org/kvm/[email protected]/
[v3]: https://lore.kernel.org/linuxppc-dev/2d2c46be7f051c7f1c645afaec67f57067d37a81.1781093720.git.ritesh.list@gmail.com/

Testing updates:
================
I have done some fair amount of testing of the selftests both on real HW and using various combinations on qemu (powernv+LE (default), pseries+cap-nested-hv, pseries+cap-nested-papr, powernv+BE). There were few powerpc kvm kernel fixes which were identified as part of this work. I will send those patches separately as those anyway needs to go in separately.

<pasted snippet of cover letter from previous versions>
=======================================================

Hi All,

This series primarly adds KVM selftests support for powerpc (64-bit, BookS, radix MMU).

This patch series is originally Nick's work. I have mainly only rebased it on the latest upstream tree. Since the rebase required few changes to all the four patches (Patch 1-4), I have dropped the earlier Acked-by from Michael Ellerman.

Since the last series was posted three years ago [1], I am resetting the version to RFC. This rebase was done as part of a larger effort to improve the selftests infrastructure for Linux on PowerPC tree. Thanks to Harsh and Maddy for their help on this.

Nicholas Piggin (1):
KVM: PPC: selftests: add support for powerpc

Ritesh Harjani (IBM) (8):
KVM: selftests: Enable kvm_create_max_vcpus test for powerpc
KVM: selftests: Don't limit LE dirty-bitmap bitops to s390x
KVM: selftests: Split out a KVM_CREATE_VCPU helper that can fail
KVM: selftests: Make kvm_create_max_vcpus tolerate ENOMEM
KVM: selftests: Limit the number of VM creates in hardware_disable_test
KVM: PPC: selftests: Make nested case on pseries LPARs as resource constrained
KVM: PPC: selftests: Skip idle-page check when running nested on pseries LPAR
KVM: selftests: Move memslot_perf_test off the 256M ELF load address

 MAINTAINERS                                   |   2 +
 tools/testing/selftests/kvm/Makefile          |   2 +-
 tools/testing/selftests/kvm/Makefile.kvm      |  10 +
 .../selftests/kvm/access_tracking_perf_test.c |  11 +
 tools/testing/selftests/kvm/dirty_log_test.c  |  12 +-
 .../selftests/kvm/hardware_disable_test.c     |   7 +-
 .../testing/selftests/kvm/include/kvm_util.h  |  13 +
 .../selftests/kvm/include/powerpc/hcall.h     |  17 +
 .../kvm/include/powerpc/kvm_util_arch.h       |  22 +
 .../selftests/kvm/include/powerpc/ppc_asm.h   |  32 ++
 .../selftests/kvm/include/powerpc/processor.h |  46 ++
 .../selftests/kvm/include/powerpc/ucall.h     |  21 +
 .../selftests/kvm/kvm_create_max_vcpus.c      |  29 +-
 tools/testing/selftests/kvm/lib/guest_modes.c |  20 +-
 tools/testing/selftests/kvm/lib/kvm_util.c    |  39 +-
 .../selftests/kvm/lib/powerpc/handlers.S      |  93 ++++
 .../testing/selftests/kvm/lib/powerpc/hcall.c |  45 ++
 .../selftests/kvm/lib/powerpc/processor.c     | 522 ++++++++++++++++++
 .../testing/selftests/kvm/lib/powerpc/ucall.c |  22 +
 .../testing/selftests/kvm/memslot_perf_test.c |   2 +-
 20 files changed, 942 insertions(+), 25 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/hcall.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/kvm_util_arch.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/ppc_asm.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/processor.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/ucall.h
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/handlers.S
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/hcall.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/processor.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/ucall.c

--
2.39.5

#1 lore raw

PATCH v5 1/9 KVM: PPC: selftests: add support for powerpc

From: Nicholas Piggin <[email protected]>

Implement KVM selftests support for powerpc (Book3S-64).

ucalls are implemented with an unsupported PAPR hcall number which will always cause KVM to exit to userspace.

Virtual memory is implemented for the radix MMU, and only a base page size is supported (both 4K and 64K).

Guest interrupts are taken in real-mode, so require a page allocated at gRA 0x0. Interrupt entry is complicated because gVA:gRA is not 1:1 mapped (like the kernel is), so the MMU can not just be switched on and off.

This patch series also changes the following types as done in other selftests. These changes are squashed in this main patch as discussed here [1]:
- Use u64 instead of uint64_t
- Use s64 instead of int64_t
- Use u32 instead of uint32_t
- Use u8 instead of uint8_t
- Replace u64 gpa, u64 gva|vaddr with gpa_t and gva_t
- Adopt to the new page table allocator APIs
- Start the guest at the entry point and not the descriptor in case of elfv1

[1]: https://lore.kernel.org/linuxppc-dev/[email protected]/
[Rebased to latest mainline tree, "cc" to clobber list, fix the
size calculation in kvm_arch_vm_post_create()]

---
 MAINTAINERS                                   |   2 +
 tools/testing/selftests/kvm/Makefile          |   2 +-
 tools/testing/selftests/kvm/Makefile.kvm      |  10 +
 .../testing/selftests/kvm/include/kvm_util.h  |   9 +
 .../selftests/kvm/include/powerpc/hcall.h     |  17 +
 .../kvm/include/powerpc/kvm_util_arch.h       |  22 +
 .../selftests/kvm/include/powerpc/ppc_asm.h   |  32 ++
 .../selftests/kvm/include/powerpc/processor.h |  39 ++
 .../selftests/kvm/include/powerpc/ucall.h     |  21 +
 tools/testing/selftests/kvm/lib/guest_modes.c |  20 +-
 tools/testing/selftests/kvm/lib/kvm_util.c    |   8 +
 .../selftests/kvm/lib/powerpc/handlers.S      |  93 ++++
 .../testing/selftests/kvm/lib/powerpc/hcall.c |  45 ++
 .../selftests/kvm/lib/powerpc/processor.c     | 512 ++++++++++++++++++
 .../testing/selftests/kvm/lib/powerpc/ucall.c |  22 +
 15 files changed, 851 insertions(+), 3 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/hcall.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/kvm_util_arch.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/ppc_asm.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/processor.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/ucall.h
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/handlers.S
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/hcall.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/processor.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/ucall.c
MAINTAINERS +2 -0
index fc320b373656..35df0c39e991 100644
@@ -14349,6 +14349,8 @@ F:	arch/powerpc/include/asm/kvm*
 F:	arch/powerpc/include/uapi/asm/kvm*
 F:	arch/powerpc/kernel/kvm*
 F:	arch/powerpc/kvm/
+F:	tools/testing/selftests/kvm/*/powerpc/
+F:	tools/testing/selftests/kvm/powerpc/
 
 KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)
 M:	Anup Patel <[email protected]>
tools/testing/selftests/kvm/Makefile +1 -1
index f2b223072b62..03d91f00092f 100644
@@ -3,7 +3,7 @@ top_srcdir = ../../../..
 include $(top_srcdir)/scripts/subarch.include
 ARCH            ?= $(SUBARCH)
 
-ifeq ($(ARCH),$(filter $(ARCH),arm64 s390 riscv x86 x86_64 loongarch))
+ifeq ($(ARCH),$(filter $(ARCH),arm64 s390 riscv x86 x86_64 loongarch powerpc))
 # Top-level selftests allows ARCH=x86_64 :-(
 ifeq ($(ARCH),x86_64)
 	override ARCH := x86
tools/testing/selftests/kvm/Makefile.kvm +10 -0
index 96bab7002d39..30f026084c6f 100644
@@ -53,6 +53,11 @@ LIBKVM_loongarch += lib/loongarch/processor.c
 LIBKVM_loongarch += lib/loongarch/ucall.c
 LIBKVM_loongarch += lib/loongarch/exception.S
 
+LIBKVM_powerpc += lib/powerpc/handlers.S
+LIBKVM_powerpc += lib/powerpc/processor.c
+LIBKVM_powerpc += lib/powerpc/ucall.c
+LIBKVM_powerpc += lib/powerpc/hcall.c
+
 # Non-compiled test targets
 TEST_PROGS_x86 += x86/nx_huge_pages_test.sh
 
@@ -251,6 +256,11 @@ TEST_GEN_PROGS_loongarch += memslot_perf_test
 TEST_GEN_PROGS_loongarch += set_memory_region_test
 TEST_GEN_PROGS_loongarch += steal_time
 
+TEST_GEN_PROGS_powerpc = $(TEST_GEN_PROGS_COMMON)
+TEST_GEN_PROGS_powerpc += access_tracking_perf_test
+TEST_GEN_PROGS_powerpc += dirty_log_perf_test
+TEST_GEN_PROGS_powerpc += hardware_disable_test
+
 SPLIT_TESTS += arch_timer
 SPLIT_TESTS += get-reg-list
 
tools/testing/selftests/kvm/include/kvm_util.h +9 -0
index 89b4fc2af751..9df16c8dc82a 100644
@@ -241,6 +241,9 @@ enum vm_guest_mode {
 	VM_MODE_P41V48_4K,
 	VM_MODE_P41V39_4K,
 
+	VM_MODE_P52V52_4K,	/* For powerpc64 */
+	VM_MODE_P52V52_64K,
+
 	NUM_VM_MODES,
 };
 
@@ -300,6 +303,12 @@ extern enum vm_guest_mode vm_mode_default;
 #define MIN_PAGE_SHIFT			12U
 #define ptes_per_page(page_size)	((page_size) / 8)
 
+#elif defined(__powerpc64__)
+
+#define VM_MODE_DEFAULT			vm_mode_default
+#define MIN_PAGE_SHIFT			12U
+#define ptes_per_page(page_size)	((page_size) / 8)
+
 #endif
 
 #define VM_SHAPE_DEFAULT	VM_SHAPE(VM_MODE_DEFAULT)
tools/testing/selftests/kvm/include/powerpc/hcall.h new file +17 -0
new file mode 100644
index 000000000000..21b2bf9180f1
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * powerpc hcall defines
+ */
+#ifndef SELFTEST_KVM_HCALL_H
+#define SELFTEST_KVM_HCALL_H
+
+#include <linux/compiler.h>
+
+/* Ucalls use unimplemented PAPR hcall 0 which exits KVM */
+#define H_UCALL	0
+
+s64 hcall0(u64 token);
+s64 hcall1(u64 token, u64 arg1);
+s64 hcall2(u64 token, u64 arg1, u64 arg2);
+
+#endif
tools/testing/selftests/kvm/include/powerpc/kvm_util_arch.h new file +22 -0
new file mode 100644
index 000000000000..5d45c25cd299
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef SELFTEST_KVM_UTIL_ARCH_H
+#define SELFTEST_KVM_UTIL_ARCH_H
+
+#include <stdint.h>
+
+#include "kvm_util_types.h"
+
+struct kvm_mmu_arch {};
+
+/* Page table fragment cache for guest page tables < page size */
+struct vm_pt_frag_cache {
+	gpa_t page;
+	size_t page_nr_used;
+};
+
+struct kvm_vm_arch {
+	gpa_t prtb; /* process table */
+	struct vm_pt_frag_cache pt_frag_cache[2]; /* 256B and 4KB PT caches */
+};
+
+#endif  /* SELFTEST_KVM_UTIL_ARCH_H */
tools/testing/selftests/kvm/include/powerpc/ppc_asm.h new file +32 -0
new file mode 100644
index 000000000000..b9df64659792
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * powerpc asm specific defines
+ */
+#ifndef SELFTEST_KVM_PPC_ASM_H
+#define SELFTEST_KVM_PPC_ASM_H
+
+#define STACK_FRAME_MIN_SIZE	112 /* Could be 32 on ELFv2 */
+#define STACK_REDZONE_SIZE	512
+
+#define INT_FRAME_SIZE		(STACK_FRAME_MIN_SIZE + STACK_REDZONE_SIZE)
+
+#define SPR_SRR0	0x01a
+#define SPR_SRR1	0x01b
+#define SPR_CFAR	0x01c
+
+#define MSR_SF		0x8000000000000000ULL
+#define MSR_HV		0x1000000000000000ULL
+#define MSR_VEC		0x0000000002000000ULL
+#define MSR_VSX		0x0000000000800000ULL
+#define MSR_EE		0x0000000000008000ULL
+#define MSR_PR		0x0000000000004000ULL
+#define MSR_FP		0x0000000000002000ULL
+#define MSR_ME		0x0000000000001000ULL
+#define MSR_IR		0x0000000000000020ULL
+#define MSR_DR		0x0000000000000010ULL
+#define MSR_RI		0x0000000000000002ULL
+#define MSR_LE		0x0000000000000001ULL
+
+#define LPCR_ILE	0x0000000002000000ULL
+
+#endif
tools/testing/selftests/kvm/include/powerpc/processor.h new file +39 -0
new file mode 100644
index 000000000000..f0ee21a8e2d4
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * powerpc processor specific defines
+ */
+#ifndef SELFTEST_KVM_PROCESSOR_H
+#define SELFTEST_KVM_PROCESSOR_H
+
+#include <linux/compiler.h>
+#include "ppc_asm.h"
+#include "kvm_util_types.h"
+
+extern unsigned char __interrupts_start[];
+extern unsigned char __interrupts_end[];
+
+struct kvm_vm;
+struct kvm_vcpu;
+
+struct ex_regs {
+	u64	gprs[32];
+	u64	nia;
+	u64	msr;
+	u64	cfar;
+	u64	lr;
+	u64	ctr;
+	u64	xer;
+	u32	cr;
+	u32	trap;
+	gva_t	gva; /* gva of this struct */
+};
+
+void vm_install_exception_handler(struct kvm_vm *vm, int vector,
+			void (*handler)(struct ex_regs *));
+
+static inline void cpu_relax(void)
+{
+	asm volatile("" ::: "memory");
+}
+
+#endif
tools/testing/selftests/kvm/include/powerpc/ucall.h new file +21 -0
new file mode 100644
index 000000000000..e0dbe91e8848
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef SELFTEST_KVM_UCALL_H
+#define SELFTEST_KVM_UCALL_H
+
+#include "hcall.h"
+
+#define UCALL_EXIT_REASON	KVM_EXIT_PAPR_HCALL
+
+#define UCALL_R4_UCALL	0x5715 /* regular ucall, r5 contains ucall pointer */
+#define UCALL_R4_SIMPLE	0x0000 /* simple exit usable by asm with no ucall data */
+
+static inline void ucall_arch_init(struct kvm_vm *vm, gpa_t mmio_gpa)
+{
+}
+
+static inline void ucall_arch_do_ucall(gva_t uc)
+{
+	hcall2(H_UCALL, UCALL_R4_UCALL, (uintptr_t)(uc));
+}
+
+#endif
tools/testing/selftests/kvm/lib/guest_modes.c +18 -2
index 7a96c43b5704..439766fad693 100644
@@ -4,16 +4,20 @@
  */
 #include "guest_modes.h"
 
-#if defined(__aarch64__) || defined(__riscv)
+#if defined(__aarch64__) || defined(__riscv) || defined(__powerpc64__)
 #include "processor.h"
 enum vm_guest_mode vm_mode_default;
 #endif
 
+#if defined(__powerpc64__)
+#include <unistd.h>
+#endif
+
 struct guest_mode guest_modes[NUM_VM_MODES];
 
 void guest_modes_append_default(void)
 {
-#if !defined(__aarch64__) && !defined(__riscv)
+#if !defined(__aarch64__) && !defined(__riscv) && !defined(__powerpc64__)
 	guest_mode_append(VM_MODE_DEFAULT, true);
 #endif
 
@@ -108,6 +112,18 @@ void guest_modes_append_default(void)
 		TEST_ASSERT(vm_mode_default != NUM_VM_MODES, "No supported mode!");
 	}
 #endif
+#ifdef __powerpc64__
+	{
+		TEST_REQUIRE(kvm_has_cap(KVM_CAP_PPC_MMU_RADIX));
+		/* Radix guest EA and RA are 52-bit on POWER9 and POWER10 */
+		if (sysconf(_SC_PAGESIZE) == 4096)
+			vm_mode_default = VM_MODE_P52V52_4K;
+		else
+			vm_mode_default = VM_MODE_P52V52_64K;
+		guest_mode_append(VM_MODE_P52V52_4K, true);
+		guest_mode_append(VM_MODE_P52V52_64K, true);
+	}
+#endif
 }
 
 void for_each_guest_mode(void (*func)(enum vm_guest_mode, void *), void *arg)
tools/testing/selftests/kvm/lib/kvm_util.c +8 -0
index 57b653fbd0b1..2be79c240ebf 100644
@@ -227,6 +227,8 @@ const char *vm_guest_mode_string(u32 i)
 		[VM_MODE_P41V57_4K]	= "PA-bits:41,  VA-bits:57,  4K pages",
 		[VM_MODE_P41V48_4K]	= "PA-bits:41,  VA-bits:48,  4K pages",
 		[VM_MODE_P41V39_4K]	= "PA-bits:41,  VA-bits:39,  4K pages",
+		[VM_MODE_P52V52_4K]	= "PA-bits:52,  VA-bits:52,  4K pages",
+		[VM_MODE_P52V52_64K]	= "PA-bits:52,  VA-bits:52, 64K pages",
 	};
 	_Static_assert(sizeof(strings)/sizeof(char *) == NUM_VM_MODES,
 		       "Missing new mode strings?");
@@ -263,6 +265,8 @@ const struct vm_guest_mode_params vm_guest_mode_params[] = {
 	[VM_MODE_P41V57_4K]	= { 41, 57,  0x1000, 12 },
 	[VM_MODE_P41V48_4K]	= { 41, 48,  0x1000, 12 },
 	[VM_MODE_P41V39_4K]	= { 41, 39,  0x1000, 12 },
+	[VM_MODE_P52V52_4K]	= { 52, 52,  0x1000, 12 },
+	[VM_MODE_P52V52_64K]	= { 52, 52, 0x10000, 16 },
 };
 _Static_assert(sizeof(vm_guest_mode_params)/sizeof(struct vm_guest_mode_params) == NUM_VM_MODES,
 	       "Missing new mode params?");
@@ -383,6 +387,10 @@ struct kvm_vm *____vm_create(struct vm_shape shape)
 	case VM_MODE_P41V39_4K:
 		vm->mmu.pgtable_levels = 3;
 		break;
+	case VM_MODE_P52V52_4K:
+	case VM_MODE_P52V52_64K:
+		vm->mmu.pgtable_levels = 4;
+		break;
 	default:
 		TEST_FAIL("Unknown guest mode: 0x%x", vm->mode);
 	}
tools/testing/selftests/kvm/lib/powerpc/handlers.S new file +93 -0

93 lines not on this page · raw message

tools/testing/selftests/kvm/lib/powerpc/hcall.c new file +45 -0

45 lines not on this page · raw message

tools/testing/selftests/kvm/lib/powerpc/processor.c new file +512 -0

512 lines not on this page · raw message

tools/testing/selftests/kvm/lib/powerpc/ucall.c new file +22 -0
new file mode 100644
index 000000000000..3481a7a0b850
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ucall support. A ucall is a "hypercall to host userspace".
+ */
+#include "kvm_util.h"
+#include "ucall_common.h"
+#include "hcall.h"
+
+void *ucall_arch_get_ucall(struct kvm_vcpu *vcpu)
+{
+	struct kvm_run *run = vcpu->run;
+
+	if (run->exit_reason == UCALL_EXIT_REASON &&
+	    run->papr_hcall.nr == H_UCALL) {
+		struct kvm_regs regs;
+
+		vcpu_regs_get(vcpu, &regs);
+		if (regs.gpr[4] == UCALL_R4_UCALL)
+			return (void *)regs.gpr[5];
+	}
+	return NULL;
+}
Signature · 1 line
2.39.5
#2 lore raw

Re: [PATCH v5 1/9] KVM: PPC: selftests: add support for powerpc

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] kvm: selftests: missing save/restore of %r1 and %r2 in ex_regs --

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] kvm: selftests: missing save/restore of %r1 and %r2 in ex_regs --

commit 2e259a0445aae14d6a7262b100f4677735b2217f
Author: Nicholas Piggin <[email protected]>

KVM: PPC: selftests: add support for powerpc

This commit implements KVM selftests support for powerpc (Book3S-64). It provides virtual memory implementation for the radix MMU, ucalls using an unsupported PAPR hcall number, and real-mode guest interrupts.

Quoted 5 lines
tools/testing/selftests/kvm/lib/powerpc/handlers.S new file +0 -0
new file mode 100644
index 0000000000000..b860f6a520a13

[ ... ]

Quoted 3 lines
tools/testing/selftests/kvm/lib/powerpc/handlers.S new file +3 -0
+virt_handle_interrupt:
+	stdu	%r1,-INT_FRAME_SIZE(%r1)
+	mr	%r3,%r31

[ ... ]

tools/testing/selftests/kvm/lib/powerpc/handlers.S line 58

Quoted 9 lines
tools/testing/selftests/kvm/lib/powerpc/handlers.S new file +9 -0
+	mtxer	%r8
+	mtcr	%r9
+reg=4
+	ld	%r0,(0*8)(%r31)
+	ld	%r3,(3*8)(%r31)
+.rept 28
+	ld	reg,(reg*8)(%r31)
+	reg=reg+1
+.endr

[Severity: Medium]
Does this restore loop in virt_handle_interrupt intentionally skip restoring %r1 (stack pointer) and %r2 (TOC base)?

Because the loop starts at reg=4 and ends at %r31, any changes made to the stack pointer or TOC base by the C exception handler in the ex_regs structure will be silently ignored when returning to the guest.

tools/testing/selftests/kvm/lib/powerpc/handlers.S line 70

Quoted 12 lines
tools/testing/selftests/kvm/lib/powerpc/handlers.S new file +12 -0
+	addi	%r1,%r1,INT_FRAME_SIZE
+	rfid
+
+virt_handle_interrupt_p:
+	.llong virt_handle_interrupt
+
+handle_interrupt:
+reg=4
+.rept 28
+	std	reg,(reg*8)(%r13)
+	reg=reg+1
+.endr

[Severity: Medium]
Similarly, does handle_interrupt skip saving %r1 and %r2 into the ex_regs structure before routing to the C handler?

If a selftest takes an exception and attempts to inspect the interrupted stack or TOC by reading regs->gprs[1] or regs->gprs[2], won't it receive uninitialized values instead of the actual register states?

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
#3 lore raw

Re: [PATCH v5 1/9] KVM: PPC: selftests: add support for powerpc

Quoted 43 lines · [email protected] writes:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] kvm: selftests: missing save/restore of %r1 and %r2 in ex_regs --

commit 2e259a0445aae14d6a7262b100f4677735b2217f
Author: Nicholas Piggin <[email protected]>

KVM: PPC: selftests: add support for powerpc

This commit implements KVM selftests support for powerpc (Book3S-64). It provides virtual memory implementation for the radix MMU, ucalls using an unsupported PAPR hcall number, and real-mode guest interrupts.

Quoted 5 lines
tools/testing/selftests/kvm/lib/powerpc/handlers.S new file +0 -0
new file mode 100644
index 0000000000000..b860f6a520a13

[ ... ]

Quoted 3 lines
tools/testing/selftests/kvm/lib/powerpc/handlers.S new file +3 -0
+virt_handle_interrupt:
+	stdu	%r1,-INT_FRAME_SIZE(%r1)
+	mr	%r3,%r31

[ ... ]

tools/testing/selftests/kvm/lib/powerpc/handlers.S line 58

Quoted 9 lines
tools/testing/selftests/kvm/lib/powerpc/handlers.S new file +9 -0
+	mtxer	%r8
+	mtcr	%r9
+reg=4
+	ld	%r0,(0*8)(%r31)
+	ld	%r3,(3*8)(%r31)
+.rept 28
+	ld	reg,(reg*8)(%r31)
+	reg=reg+1
+.endr

[Severity: Medium]
Does this restore loop in virt_handle_interrupt intentionally skip restoring %r1 (stack pointer) and %r2 (TOC base)?

Quoted 4 lines

Because the loop starts at reg=4 and ends at %r31, any changes made to the stack pointer or TOC base by the C exception handler in the ex_regs structure will be silently ignored when returning to the guest.

That is intentional since it is unnecessary.

Quoted 17 lines

tools/testing/selftests/kvm/lib/powerpc/handlers.S line 70

Quoted 12 lines
tools/testing/selftests/kvm/lib/powerpc/handlers.S new file +12 -0
+	addi	%r1,%r1,INT_FRAME_SIZE
+	rfid
+
+virt_handle_interrupt_p:
+	.llong virt_handle_interrupt
+
+handle_interrupt:
+reg=4
+.rept 28
+	std	reg,(reg*8)(%r13)
+	reg=reg+1
+.endr

[Severity: Medium]
Similarly, does handle_interrupt skip saving %r1 and %r2 into the ex_regs structure before routing to the C handler?

Quoted 4 lines

If a selftest takes an exception and attempts to inspect the interrupted stack or TOC by reading regs->gprs[1] or regs->gprs[2], won't it receive uninitialized values instead of the actual register states?

ditto. None of the tests depend on it.

Quoted 2 lines
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
#4 lore raw

Re: [PATCH v5 1/9] KVM: PPC: selftests: add support for powerpc

In reply to Ritesh Harjani (IBM)
Quoted 32 lines · Ritesh Harjani (IBM)
---
 MAINTAINERS                                   |   2 +
 tools/testing/selftests/kvm/Makefile          |   2 +-
 tools/testing/selftests/kvm/Makefile.kvm      |  10 +
 .../testing/selftests/kvm/include/kvm_util.h  |   9 +
 .../selftests/kvm/include/powerpc/hcall.h     |  17 +
 .../kvm/include/powerpc/kvm_util_arch.h       |  22 +
 .../selftests/kvm/include/powerpc/ppc_asm.h   |  32 ++
 .../selftests/kvm/include/powerpc/processor.h |  39 ++
 .../selftests/kvm/include/powerpc/ucall.h     |  21 +
 tools/testing/selftests/kvm/lib/guest_modes.c |  20 +-
 tools/testing/selftests/kvm/lib/kvm_util.c    |   8 +
 .../selftests/kvm/lib/powerpc/handlers.S      |  93 ++++
 .../testing/selftests/kvm/lib/powerpc/hcall.c |  45 ++
 .../selftests/kvm/lib/powerpc/processor.c     | 512 ++++++++++++++++++
 .../testing/selftests/kvm/lib/powerpc/ucall.c |  22 +
 15 files changed, 851 insertions(+), 3 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/hcall.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/kvm_util_arch.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/ppc_asm.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/processor.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/ucall.h
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/handlers.S
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/hcall.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/processor.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/ucall.c
MAINTAINERS +0 -0
index fc320b373656..35df0c39e991 100644

MAINTAINERS F: arch/powerpc/include/asm/kvm* · line 14353

Quoted 5 lines
MAINTAINERS +2 -0
@@ -14349,6 +14349,8 @@ F:	arch/powerpc/include/asm/kvm*
 F:	arch/powerpc/include/uapi/asm/kvm*
 F:	arch/powerpc/kernel/kvm*
 F:	arch/powerpc/kvm/
+F:	tools/testing/selftests/kvm/*/powerpc/
+F:	tools/testing/selftests/kvm/powerpc/

I don't think sending KVM PPC selftests changes through the PPC tree will work. It's "fine" for KVM PPC changes because the volume of KVM PPC changes is low and rarely modifies anything outside of arch/powerpc.

KVM selftests tend to have a lot more cross-arch and/or common code modifications, i.e. I think we'll be setting ourselves up for pain if we don't route all KVM selftests changes through Paolo's tree.

Does it maybe make sense to have all of KVM PPC route through Paolo? Punting to PPC made sense when KVM PPC was on life support, but it looks like resuscitation was successful for at least some flavors of KVM PPC?

#5 lore raw

Re: [PATCH v5 1/9] KVM: PPC: selftests: add support for powerpc

Quoted 43 lines · Sean Christopherson
Quoted 32 lines · Ritesh Harjani (IBM)
---
 MAINTAINERS                                   |   2 +
 tools/testing/selftests/kvm/Makefile          |   2 +-
 tools/testing/selftests/kvm/Makefile.kvm      |  10 +
 .../testing/selftests/kvm/include/kvm_util.h  |   9 +
 .../selftests/kvm/include/powerpc/hcall.h     |  17 +
 .../kvm/include/powerpc/kvm_util_arch.h       |  22 +
 .../selftests/kvm/include/powerpc/ppc_asm.h   |  32 ++
 .../selftests/kvm/include/powerpc/processor.h |  39 ++
 .../selftests/kvm/include/powerpc/ucall.h     |  21 +
 tools/testing/selftests/kvm/lib/guest_modes.c |  20 +-
 tools/testing/selftests/kvm/lib/kvm_util.c    |   8 +
 .../selftests/kvm/lib/powerpc/handlers.S      |  93 ++++
 .../testing/selftests/kvm/lib/powerpc/hcall.c |  45 ++
 .../selftests/kvm/lib/powerpc/processor.c     | 512 ++++++++++++++++++
 .../testing/selftests/kvm/lib/powerpc/ucall.c |  22 +
 15 files changed, 851 insertions(+), 3 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/hcall.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/kvm_util_arch.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/ppc_asm.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/processor.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/ucall.h
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/handlers.S
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/hcall.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/processor.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/ucall.c
MAINTAINERS +0 -0
index fc320b373656..35df0c39e991 100644

MAINTAINERS F: arch/powerpc/include/asm/kvm* · line 14353

Quoted 5 lines
MAINTAINERS +2 -0
@@ -14349,6 +14349,8 @@ F:	arch/powerpc/include/asm/kvm*
 F:	arch/powerpc/include/uapi/asm/kvm*
 F:	arch/powerpc/kernel/kvm*
 F:	arch/powerpc/kvm/
+F:	tools/testing/selftests/kvm/*/powerpc/
+F:	tools/testing/selftests/kvm/powerpc/

I don't think sending KVM PPC selftests changes through the PPC tree will work. It's "fine" for KVM PPC changes because the volume of KVM PPC changes is low and rarely modifies anything outside of arch/powerpc.

Quoted 4 lines

KVM selftests tend to have a lot more cross-arch and/or common code modifications, i.e. I think we'll be setting ourselves up for pain if we don't route all KVM selftests changes through Paolo's tree.

Sure, since enabling kvm selftests on powerpc has quite a few common changes in cross-arch, so it make sense to take it via common tree which it already uses.

BTW - the above file name paths are just so that we can have people cc linuxppc-dev too, for powerpc kvm selftests changes.

Quoted 3 lines

Does it maybe make sense to have all of KVM PPC route through Paolo? Punting to PPC made sense when KVM PPC was on life support, but it looks like resuscitation was successful for at least some flavors of KVM PPC?

Today, I think it is getting managed, as long as the core/UAPI changes are routed via Paolo and/or via ACK from both maintainers.

However, for PPC kvm selftests - let's do as discussed - to take it via common kvm tree.

Thanks again Sean, for the review. I will soon post v6 with the suggested approach.

-ritesh

#6 lore raw

PATCH v5 2/9 KVM: selftests: Enable kvm_create_max_vcpus test for powerpc

In reply to Ritesh Harjani (IBM)

powerpc's maximum permitted vCPU ID depends on the VM's SMT mode, and the maximum reported by KVM_CAP_MAX_VCPU_ID exceeds a simple non-SMT VM's limit.

The powerpc KVM selftest port uses non-SMT VMs, so add a workaround to the kvm_create_max_vcpus test case to limit vCPU IDs to KVM_CAP_MAX_VCPUS on powerpc.
This patch allows us to skip the vCPU ID test when running on PowerPC with SMT support, in which case system topology is encoded into the vCPU ID, and so a VM can't use the full advertised vCPU ID range without crafting a valid platform specific topology.

---
 tools/testing/selftests/kvm/kvm_create_max_vcpus.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
tools/testing/selftests/kvm/kvm_create_max_vcpus.c +7 -1
index c5310736ed06..59ddc3757943 100644
@@ -58,7 +58,13 @@ int main(int argc, char *argv[])
 
 	test_vcpu_creation(0, kvm_max_vcpus);
 
-	if (kvm_max_vcpu_id > kvm_max_vcpus)
+	/*
+	 * Skip the vCPU ID test when running on PowerPC with SMT support, in
+	 * which case system topology is encoded into the vCPU ID, and so a VM
+	 * can't use the full advertised vCPU ID range without crafting a valid
+	 * platform specific topology.
+	 */
+	if (kvm_max_vcpu_id > kvm_max_vcpus && !kvm_check_cap(KVM_CAP_PPC_SMT))
 		test_vcpu_creation(
 			kvm_max_vcpu_id - kvm_max_vcpus, kvm_max_vcpus);
 
Signature · 1 line
2.39.5
#7 lore raw

PATCH v5 3/9 KVM: selftests: Don't limit LE dirty-bitmap bitops to s390x

In reply to Ritesh Harjani (IBM)

dirty_log_test already has BITOP_LE_SWIZZLE helpers, but they were compiled in only for s390x, so every other big-endian host used native test_bit().

The test fails on big-endian powerpc because it treated dirty host pages as clean (because of the endianness issue)

w/o the fix the test fails with:
Clear page 1 value (1) >= iteration (1)

Fixes a049a377164c ("KVM: selftests: Enable dirty_log_test on s390x")
---
 tools/testing/selftests/kvm/dirty_log_test.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)
tools/testing/selftests/kvm/dirty_log_test.c +4 -8
index af5eb0334a74..8189eaac713c 100644
@@ -44,8 +44,11 @@
 #define TEST_MIN_WRITES_PER_ITERATION	0x100
 
 /* Dirty bitmaps are always little endian, so we need to swap on big endian */
-#if defined(__s390x__)
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
 # define BITOP_LE_SWIZZLE	((BITS_PER_LONG-1) & ~0x7)
+#else
+# define BITOP_LE_SWIZZLE	0
+#endif
 # define test_bit_le(nr, addr) \
 	test_bit((nr) ^ BITOP_LE_SWIZZLE, addr)
 # define __set_bit_le(nr, addr) \
@@ -56,13 +59,6 @@
 	__test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, addr)
 # define __test_and_clear_bit_le(nr, addr) \
 	__test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, addr)
-#else
-# define test_bit_le			test_bit
-# define __set_bit_le			__set_bit
-# define __clear_bit_le			__clear_bit
-# define __test_and_set_bit_le		__test_and_set_bit
-# define __test_and_clear_bit_le	__test_and_clear_bit
-#endif
 
 #define TEST_DIRTY_RING_COUNT		65536
 
Signature · 1 line
2.39.5
#8 lore raw

PATCH v5 4/9 KVM: selftests: Split out a KVM_CREATE_VCPU helper that can fail

In reply to Ritesh Harjani (IBM)

__vm_vcpu_add() currently asserts on KVM_CREATE_VCPU, which is what most callers want. But sometimes a test may want to handle ENOMEM without dropping all that other setup that __vm_vcpu_add() has.

This patch adds a helper __vm_vcpu_try_add() for such test cases and make __vm_vcpu_add() a wrapper around that.

---
 .../testing/selftests/kvm/include/kvm_util.h  |  1 +
 tools/testing/selftests/kvm/lib/kvm_util.c    | 26 ++++++++++++++-----
 2 files changed, 21 insertions(+), 6 deletions(-)
tools/testing/selftests/kvm/include/kvm_util.h +1 -0
index 9df16c8dc82a..aa521b383abe 100644
@@ -784,6 +784,7 @@ void vm_mem_region_set_flags(struct kvm_vm *vm, u32 slot, u32 flags);
 void vm_mem_region_reload(struct kvm_vm *vm, u32 slot);
 void vm_mem_region_move(struct kvm_vm *vm, u32 slot, u64 new_gpa);
 void vm_mem_region_delete(struct kvm_vm *vm, u32 slot);
+struct kvm_vcpu *__vm_vcpu_try_add(struct kvm_vm *vm, u32 vcpu_id);
 struct kvm_vcpu *__vm_vcpu_add(struct kvm_vm *vm, u32 vcpu_id);
 void vm_populate_gva_bitmap(struct kvm_vm *vm);
 gva_t vm_unused_gva_gap(struct kvm_vm *vm, size_t sz, gva_t min_gva);
tools/testing/selftests/kvm/lib/kvm_util.c +20 -6
index 2be79c240ebf..7084ed90e4cc 100644
@@ -1367,11 +1367,7 @@ static bool vcpu_exists(struct kvm_vm *vm, u32 vcpu_id)
 	return false;
 }
 
-/*
- * Adds a virtual CPU to the VM specified by vm with the ID given by vcpu_id.
- * No additional vCPU setup is done.  Returns the vCPU.
- */
-struct kvm_vcpu *__vm_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
+struct kvm_vcpu *__vm_vcpu_try_add(struct kvm_vm *vm, u32 vcpu_id)
 {
 	struct kvm_vcpu *vcpu;
 
@@ -1385,7 +1381,13 @@ struct kvm_vcpu *__vm_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
 	vcpu->vm = vm;
 	vcpu->id = vcpu_id;
 	vcpu->fd = __vm_ioctl(vm, KVM_CREATE_VCPU, (void *)(unsigned long)vcpu_id);
-	TEST_ASSERT_VM_VCPU_IOCTL(vcpu->fd >= 0, KVM_CREATE_VCPU, vcpu->fd, vm);
+	if (vcpu->fd < 0) {
+		int __errno = errno;
+
+		free(vcpu);
+		errno = __errno;
+		return NULL;
+	}
 
 	TEST_ASSERT(vcpu_mmap_sz() >= sizeof(*vcpu->run), "vcpu mmap size "
 		"smaller than expected, vcpu_mmap_sz: %zi expected_min: %zi",
@@ -1404,6 +1406,18 @@ struct kvm_vcpu *__vm_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
 	return vcpu;
 }
 
+/*
+ * Adds a virtual CPU to the VM specified by vm with the ID given by vcpu_id.
+ * No additional vCPU setup is done.  Returns the vCPU.
+ */
+struct kvm_vcpu *__vm_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
+{
+	struct kvm_vcpu *vcpu = __vm_vcpu_try_add(vm, vcpu_id);
+
+	TEST_ASSERT_VM_VCPU_IOCTL(vcpu, KVM_CREATE_VCPU, -1, vm);
+	return vcpu;
+}
+
 /*
  * Within the VM specified by @vm, locates the lowest starting guest virtual
  * address >= @min_gva, that has at least @sz unallocated bytes.  A
Signature · 1 line
2.39.5
#9 lore raw

PATCH v5 5/9 KVM: selftests: Make kvm_create_max_vcpus tolerate ENOMEM

In reply to Ritesh Harjani (IBM)

Some hosts (like in case of nested guest the hypervisor L0 might have quotas/limited resources for L1 guest) can run out of hypervisor resources before hitting KVM_CAP_MAX_VCPUS.

This patch make use of the helper we introduced in the previous patch (__vm_vcpu_try_add()) to tolerate such scenarios where an ENOMEM can occur.

---
 .../testing/selftests/kvm/include/kvm_util.h  |  3 +++
 .../selftests/kvm/kvm_create_max_vcpus.c      | 21 +++++++++++++++----
 tools/testing/selftests/kvm/lib/kvm_util.c    |  5 +++++
 3 files changed, 25 insertions(+), 4 deletions(-)
tools/testing/selftests/kvm/include/kvm_util.h +3 -0
index aa521b383abe..576bbebe0679 100644
@@ -1064,6 +1064,9 @@ const char *exit_reason_str(unsigned int exit_reason);
 
 bool kvm_arch_needs_naturally_aligned_page_tables(void);
 
+/* True if KVM_CREATE_VM / KVM_CREATE_VCPU may return ENOMEM. */
+bool kvm_arch_vm_create_may_enomem(void);
+
 gpa_t ____vm_phy_pages_alloc(struct kvm_vm *vm, size_t nr_pages, gpa_t min_gpa,
 			     u32 memslot, bool protected, bool naturally_aligned);
 gpa_t __vm_phy_pages_alloc(struct kvm_vm *vm, size_t nr_pages,
tools/testing/selftests/kvm/kvm_create_max_vcpus.c +17 -4
index 59ddc3757943..45a9d8b369b5 100644
@@ -20,16 +20,29 @@
 void test_vcpu_creation(int first_vcpu_id, int num_vcpus)
 {
 	struct kvm_vm *vm;
-	int i;
+	struct kvm_vcpu *vcpu;
+	int i, created = 0;
 
 	pr_info("Testing creating %d vCPUs, with IDs %d...%d.\n",
 		num_vcpus, first_vcpu_id, first_vcpu_id + num_vcpus - 1);
 
 	vm = vm_create_barebones();
 
-	for (i = first_vcpu_id; i < first_vcpu_id + num_vcpus; i++)
-		/* This asserts that the vCPU was created. */
-		__vm_vcpu_add(vm, i);
+	for (i = first_vcpu_id; i < first_vcpu_id + num_vcpus; i++) {
+		vcpu = __vm_vcpu_try_add(vm, i);
+		if (vcpu) {
+			created++;
+			continue;
+		}
+
+		TEST_ASSERT(errno == ENOMEM && kvm_arch_vm_create_may_enomem(),
+			    "KVM_CREATE_VCPU failed for id %d, errno: %d (%s)",
+			    i, errno, strerror(errno));
+		TEST_ASSERT(created > 0,
+			    "KVM_CREATE_VCPU failed with ENOMEM before creating any vCPUs");
+		pr_info("Created %d vCPUs before ENOMEM at id %d\n", created, i);
+		break;
+	}
 
 	kvm_vm_free(vm);
 }
tools/testing/selftests/kvm/lib/kvm_util.c +5 -0
index 7084ed90e4cc..b4d6b8167466 100644
@@ -2112,6 +2112,11 @@ __weak bool kvm_arch_needs_naturally_aligned_page_tables(void)
 	return false;
 }
 
+__weak bool kvm_arch_vm_create_may_enomem(void)
+{
+	return false;
+}
+
 gpa_t __vm_phy_pages_alloc(struct kvm_vm *vm, size_t nr_pages,
 			   enum kvm_mem_region_type type, bool protected)
 {
Signature · 1 line
2.39.5
#10 lore raw

Re: [PATCH v5 5/9] KVM: selftests: Make kvm_create_max_vcpus tolerate ENOMEM

Quoted 16 lines · Ritesh Harjani (IBM)
tools/testing/selftests/kvm/kvm_create_max_vcpus.c +2 -1
index 59ddc3757943..45a9d8b369b5 100644
@@ -20,16 +20,29 @@
 void test_vcpu_creation(int first_vcpu_id, int num_vcpus)
 {
 	struct kvm_vm *vm;
-	int i;
+	struct kvm_vcpu *vcpu;
+	int i, created = 0;
 
 	pr_info("Testing creating %d vCPUs, with IDs %d...%d.\n",
 		num_vcpus, first_vcpu_id, first_vcpu_id + num_vcpus - 1);
 
 	vm = vm_create_barebones();

tools/testing/selftests/kvm/kvm_create_max_vcpus.c line 36

Quoted 10 lines
tools/testing/selftests/kvm/kvm_create_max_vcpus.c +6 -3
 
-	for (i = first_vcpu_id; i < first_vcpu_id + num_vcpus; i++)
-		/* This asserts that the vCPU was created. */
-		__vm_vcpu_add(vm, i);
+	for (i = first_vcpu_id; i < first_vcpu_id + num_vcpus; i++) {
+		vcpu = __vm_vcpu_try_add(vm, i);
+		if (vcpu) {
+			created++;
+			continue;
+		}

Oof. I dislike this, to put it very mildly. Is this the KVM_CAP_PPC_SMT thing again, or something else?

Assuming it's KVM_CAP_PPC_SMT, is there really no way userspace can pre-probe the "real" limit? Or modify the test to enable KVM_CAP_PPC_SMT and do the proper striding? Eating -ENOMEM is all kinds of gross, and I really don't want to add __vm_vcpu_try_add().

#11 lore raw

Re: [PATCH v5 5/9] KVM: selftests: Make kvm_create_max_vcpus tolerate ENOMEM

Quoted 18 lines · Sean Christopherson
Quoted 17 lines · Ritesh Harjani (IBM)
tools/testing/selftests/kvm/kvm_create_max_vcpus.c +2 -1
index 59ddc3757943..45a9d8b369b5 100644
@@ -20,16 +20,29 @@
 void test_vcpu_creation(int first_vcpu_id, int num_vcpus)
 {
 	struct kvm_vm *vm;
-	int i;
+	struct kvm_vcpu *vcpu;
+	int i, created = 0;
 
 	pr_info("Testing creating %d vCPUs, with IDs %d...%d.\n",
 		num_vcpus, first_vcpu_id, first_vcpu_id + num_vcpus - 1);
 
 	vm = vm_create_barebones();
 
Quoted 13 lines

tools/testing/selftests/kvm/kvm_create_max_vcpus.c line 36

Quoted 9 lines
tools/testing/selftests/kvm/kvm_create_max_vcpus.c +6 -3
-	for (i = first_vcpu_id; i < first_vcpu_id + num_vcpus; i++)
-		/* This asserts that the vCPU was created. */
-		__vm_vcpu_add(vm, i);
+	for (i = first_vcpu_id; i < first_vcpu_id + num_vcpus; i++) {
+		vcpu = __vm_vcpu_try_add(vm, i);
+		if (vcpu) {
+			created++;
+			continue;
+		}

Oof. I dislike this, to put it very mildly. Is this the KVM_CAP_PPC_SMT thing again, or something else?

No, this is not the SMT issue, where PowerPC encodes topology in the id, so we cannot use the full MAX_VCPU_ID range without a valid SMT layout. That problem we have fixed in Patch-2.

This is resource limitation on L0 Hypervisor for KVM-on-PowerVM (nestedv2) case. On nestedv2, KVM_CREATE_VCPU is an hcall to the PowerVM hypervisor (H_GUEST_CREATE_VCPU). Now MAX_VCPUS or the MAX_VCPU_ID are the max vcpuid range limits, but that is not a promise. L0 can still run out of guest management space, i.e. the hcall can fail with H_Not_Enough_Resources error as per platform HCALL specification. KVM maps this hcall's out of resource error to -ENOMEM.

Quoted 4 lines

Assuming it's KVM_CAP_PPC_SMT, is there really no way userspace can pre-probe the "real" limit? Or modify the test to enable KVM_CAP_PPC_SMT and do the proper striding? Eating -ENOMEM is all kinds of gross, and I really don't want to add __vm_vcpu_try_add().

We already probed for max vcpu id range limit. I don't think userspace can probe for anything else here. But let me think about this a bit and get back. Maybe I can see if I can drop the helper.

-ritesh

#12 lore raw

PATCH v5 6/9 KVM: selftests: Limit the number of VM creates in hardware_disable_test

In reply to Ritesh Harjani (IBM)

hardware_disable_test forks several VMs (NR_IERATIONS=512). This patch limits that number to 4 when we know that we are running in constraint host environment. The number 4 is just a safe minimum when kvm_arch_vm_create_may_enomem() can be true.

---
 tools/testing/selftests/kvm/hardware_disable_test.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
tools/testing/selftests/kvm/hardware_disable_test.c +5 -2
index 43a36ef3ead8..e90a17b8160e 100644
@@ -20,6 +20,7 @@
 #define NR_VCPUS		4
 #define NR_SLEEPERS_PER_VCPU	16
 #define NR_ITERATIONS		512
+#define NR_ITERATIONS_LIMIT	4
 #define DELAY_US_MAX		2000
 
 static cpu_set_t threads_cpu_set;
@@ -127,7 +128,7 @@ void wait_for_child_setup(pid_t pid)
 int main(int argc, char **argv)
 {
 	cpu_set_t allowed_cpu_set;
-	int s, r, cpu, i;
+	int s, r, cpu, i, nr_iterations;
 	pid_t pid;
 
 	kvm_sched_getaffinity(0, sizeof(cpu_set_t), &allowed_cpu_set);
@@ -141,7 +142,9 @@ int main(int argc, char **argv)
 	sem = sem_open("vm_sem", O_CREAT | O_EXCL, 0644, 0);
 	sem_unlink("vm_sem");
 
-	for (i = 0; i < NR_ITERATIONS; ++i) {
+	nr_iterations = kvm_arch_vm_create_may_enomem() ? NR_ITERATIONS_LIMIT :
+							  NR_ITERATIONS;
+	for (i = 0; i < nr_iterations; ++i) {
 		pid = fork();
 		TEST_ASSERT(pid >= 0, "%s: unable to fork", __func__);
 		if (pid == 0)
Signature · 1 line
2.39.5
#13 lore raw

Re: [PATCH v5 6/9] KVM: selftests: Limit the number of VM creates in hardware_disable_test

Quoted 4 lines · Ritesh Harjani (IBM)

hardware_disable_test forks several VMs (NR_IERATIONS=512). This patch limits that number to 4 when we know that we are running in constraint host environment. The number 4 is just a safe minimum when kvm_arch_vm_create_may_enomem() can be true.

Please actually explain *why* this is necessary, and where the magic '4' comes. I assume there's some system-wide resource at play?

#14 lore raw

Re: [PATCH v5 6/9] KVM: selftests: Limit the number of VM creates in hardware_disable_test

Quoted 8 lines · Sean Christopherson
Quoted 4 lines · Ritesh Harjani (IBM)

hardware_disable_test forks several VMs (NR_IERATIONS=512). This patch limits that number to 4 when we know that we are running in constraint host environment. The number 4 is just a safe minimum when kvm_arch_vm_create_may_enomem() can be true.

Please actually explain *why* this is necessary, and where the magic '4' comes. I assume there's some system-wide resource at play?

Yes, this is the similar issue of limited resources at L0 for nested-v2 case. This test actually forks and each child creates a VM. Here, the parent queues the SIGKILL for the child, however it does not waitpid before the next fork. That means the VM can still be eating the guest management space at L0 for the nested-v2 guests (until the VM is completely destroyed).

I agree the number 4 is a bit ugly here. It was just a safe limit. I was able to spawn multiple VMs ofcourse - but for the sake of enabling this test I went with some safe minimum.

BTW, since you suggested that in the initial enablement of the kvm PPC selftests, we need not land this hardware_disable_test, so I will skip this for now.

-ritesh

#15 lore raw

PATCH v5 7/9 KVM: PPC: selftests: Make nested case on pseries LPARs as resource constrained

In reply to Ritesh Harjani (IBM)

For nested guest case (L1 as pseries LPAR), L0 may fail with -44 (H_NOT_ENOUGH_RESOURCES) during vm or vcpu creation, causing enomem due to limited resource/quotas.
This adds the necessary arch hooks for the same so that it can survive hardware_disable_test and kvm_create_max_vcpus test cases.

---
 .../testing/selftests/kvm/include/powerpc/processor.h  |  7 +++++++
 tools/testing/selftests/kvm/lib/powerpc/processor.c    | 10 ++++++++++
 2 files changed, 17 insertions(+)
tools/testing/selftests/kvm/include/powerpc/processor.h +7 -0
index f0ee21a8e2d4..a46f6828991c 100644
@@ -6,6 +6,8 @@
 #define SELFTEST_KVM_PROCESSOR_H
 
 #include <linux/compiler.h>
+#include <unistd.h>
+
 #include "ppc_asm.h"
 #include "kvm_util_types.h"
 
@@ -36,4 +38,9 @@ static inline void cpu_relax(void)
 	asm volatile("" ::: "memory");
 }
 
+static inline bool is_pseries_lpar(void)
+{
+	return !access("/proc/device-tree/rtas/ibm,hypertas-functions", F_OK);
+}
+
 #endif
tools/testing/selftests/kvm/lib/powerpc/processor.c +10 -0
index 301455024571..e5d84f6d82f2 100644
@@ -23,6 +23,16 @@ bool kvm_arch_needs_naturally_aligned_page_tables(void)
 	return true;
 }
 
+/*
+ * For nested guest case (L1 as pseries LPAR), L0 may fail with -44
+ * (H_NOT_ENOUGH_RESOURCES) during vm or vcpu creation, causing enomem
+ * due to limited resource/quotas.
+ */
+bool kvm_arch_vm_create_may_enomem(void)
+{
+	return is_pseries_lpar();
+}
+
 static void set_proc_table(struct kvm_vm *vm, int pid, u64 dw0, u64 dw1)
 {
 	u64 *proc_table;
Signature · 1 line
2.39.5
#16 lore raw

PATCH v5 8/9 KVM: PPC: selftests: Skip idle-page check when running nested on pseries LPAR

In reply to Ritesh Harjani (IBM)

Same nested TLB/access bit issue like x86. Use the is_pseries_lpar() check to detect when running nested kvm on pseries LPAR to only warn on idle-page check.

---
 .../testing/selftests/kvm/access_tracking_perf_test.c | 11 +++++++++++
 1 file changed, 11 insertions(+)
tools/testing/selftests/kvm/access_tracking_perf_test.c +11 -0
index 4415c94b2866..94bfb82f7b79 100644
@@ -470,6 +470,17 @@ static int access_tracking_unreliable(void)
 		puts("Skipping idle page count sanity check, because the test is run nested");
 		return 1;
 	}
+#endif
+#ifdef __powerpc64__
+	/*
+	 * Nested KVM (pSeries LPAR) can hide accessed/idle, since KVM doesn't
+	 * explicitely flush the TLB for access bit update. L0 keeps
+	 * translations cached so the guest won't see the idle bit cleared.
+	 */
+	if (is_pseries_lpar()) {
+		puts("Skipping idle page count sanity check, because the test is run nested");
+		return 1;
+	}
 #endif
 	/*
 	 * When NUMA balancing is enabled, guest memory will be unmapped to get
Signature · 1 line
2.39.5
#17 lore raw

PATCH v5 9/9 KVM: selftests: Move memslot_perf_test off the 256M ELF load address

In reply to Ritesh Harjani (IBM)

KVM selftests are built with -fno-PIE/-no-pie so the binary uses fixed load addresses.
On powerpc64, GNU ld default links at 0x10000000 (256M) which is also the MEM_GPA, so the identity map trips with the error:
PTE already present at level: 4 gva: 0x10000000 pte:0xc00000000002018f

Put the test slots at 512M instead which is past the ELF. e.g. failure w/o this fix:

./memslot_perf_test -s 514
Random seed: 0x423558ef
Testing map performance with 1 runs, 5 seconds each

==== Test Assertion Failure ====
lib/powerpc/processor.c:235: !pte
pid=371 tid=371 errno=2 - No such file or directory

     1  0x0000000010018293: virt_arch_pg_map at processor.c:235
     2  0x0000000010008b3f: virt_pg_map at kvm_util.h:1325
     3   (inlined by) virt_map at kvm_util.c:1571
     4  0x0000000010001cab: prepare_vm at memslot_perf_test.c:353
     5   (inlined by) test_execute at memslot_perf_test.c:816
     6   (inlined by) test_loop at memslot_perf_test.c:1062
     7   (inlined by) main at memslot_perf_test.c:1136
     8  0x000000001001d713: __libc_start_call_main at libc-start.o:?
     9  0x000000001001db47: __libc_start_main_impl at ??:?

PTE already present at level: 4 gva: 0x10000000 pte:0xc00000000002018f

---
 tools/testing/selftests/kvm/memslot_perf_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/kvm/memslot_perf_test.c +1 -1
index 844ea9b7bb41..2913a4de4cc9 100644
@@ -30,7 +30,7 @@
 #define MEM_EXTRA_SIZE		SZ_64K
 
 #define MEM_SIZE		(SZ_512M + MEM_EXTRA_SIZE)
-#define MEM_GPA			SZ_256M
+#define MEM_GPA			SZ_512M
 #define MEM_AUX_GPA		MEM_GPA
 #define MEM_SYNC_GPA		MEM_AUX_GPA
 #define MEM_TEST_GPA		(MEM_AUX_GPA + MEM_EXTRA_SIZE)

--
2.39.5

#18 lore raw

Re: [PATCH v5 9/9] KVM: selftests: Move memslot_perf_test off the 256M ELF load address

Quoted 10 lines · Ritesh Harjani (IBM)

KVM selftests are built with -fno-PIE/-no-pie so the binary uses fixed load addresses.
On powerpc64, GNU ld default links at 0x10000000 (256M) which is also the MEM_GPA, so the identity map trips with the error:
PTE already present at level: 4 gva: 0x10000000 pte:0xc00000000002018f

Put the test slots at 512M instead which is past the ELF. e.g. failure w/o this fix:

./memslot_perf_test -s 514

This, and any other adjustments/fixes to get common test functional on PPC needs to land *before* the tests are enabled.

#19 lore raw
In reply to Ritesh Harjani (IBM)
Quoted 5 lines · Ritesh Harjani (IBM)

Hi All,

This series primarly adds KVM selftests support for powerpc (64-bit, BookS, radix MMU).

Hello Sean,

Just wanted to check what's our plan on this one? Are we planning for both PPC pre-enablement series of yours and this one to be taken for v7.4 merge? Do you think this can go in too?

Thanks for your help!

-ritesh

#20 lore raw
Quoted 11 lines · Ritesh Harjani
Quoted 5 lines · Ritesh Harjani (IBM)

Hi All,

This series primarly adds KVM selftests support for powerpc (64-bit, BookS, radix MMU).

Hello Sean,

Just wanted to check what's our plan on this one?

At this point, I'm not going to get a pull request to Paolo before the normal merge window. I was hoping/planning to get some early pull requests to Paolo this cycle so y'all could build on kvm/next directly, but that didn't happen.

Quoted 2 lines

Are we planning for both PPC pre-enablement series of yours and this one to be taken for v7.4 merge? Do you think this can go in too?

I'd like to get at least a subset of this series in for 7.4. If I'm reading things correctly, all of the hacky changes I don't like are for the kvm_create_max_vcpus_test and hardware_disable_test. And as called out in the final patch, "fixes" for PPC really should be ordered so that they land *before* the tests are enabled.

Actually, better idea. Limit patch 1 to just TEST_GEN_PROGS_COMMON, then for the addon tests, bundle the "fix" with the PPC enablement. AFAICT, except for the kvm_create_max_vcpus changes, they're all pretty small, i.e. bundling the PPC support with the "fix" shouldn't be too painful, and then we don't have to worry about ordering.

As for kvm_create_max_vcpus and hardware_disable_test, drop them from the initial enablement so we can get the core support landed, and tackle them as separate series post-7.4.

As for actually landing this, the easiest thing at this point would probably be for me to grab the patches in a dedicated topic branch that's based off the kvm-x86/selftests branch at an appropriate point in time. Alternatively, I could provide a stable tag and someone else could grab the patches, but other than it being a little weird taking PPC changes through kvm-x86, that's by far the easiest approach since I'll be sending Paolo pull requests anyways and can explain the dependencies and whatnot.

TL;DR: what if you post a slightly trimmed-down v6 and I take it through kvm-x86?

#21 lore raw
Quoted 26 lines · Sean Christopherson
Quoted 11 lines · Ritesh Harjani
Quoted 5 lines · Ritesh Harjani (IBM)

Hi All,

This series primarly adds KVM selftests support for powerpc (64-bit, BookS, radix MMU).

Hello Sean,

Just wanted to check what's our plan on this one?

At this point, I'm not going to get a pull request to Paolo before the normal merge window. I was hoping/planning to get some early pull requests to Paolo this cycle so y'all could build on kvm/next directly, but that didn't happen.

Quoted 2 lines

Are we planning for both PPC pre-enablement series of yours and this one to be taken for v7.4 merge? Do you think this can go in too?

I'd like to get at least a subset of this series in for 7.4. If I'm reading things correctly, all of the hacky changes I don't like are for the kvm_create_max_vcpus_test and hardware_disable_test. And as called out in the final patch, "fixes" for PPC really should be ordered so that they land *before* the tests are enabled.

Quoted 6 lines

Actually, better idea. Limit patch 1 to just TEST_GEN_PROGS_COMMON, then for the addon tests, bundle the "fix" with the PPC enablement. AFAICT, except for the kvm_create_max_vcpus changes, they're all pretty small, i.e. bundling the PPC support with the "fix" shouldn't be too painful, and then we don't have to worry about ordering.

Sure, will take the suggested route then. Will bundle the Makefile enablement change and the needed fix in the same patch to avoid the ordering issue.

Also note - I will open code the TEST_GEN_PROGS_COMMON and will skip the kvm_create_max_vcpus (& maybe few others like vm_types_test) from that in v6.

Quoted 4 lines

As for kvm_create_max_vcpus and hardware_disable_test, drop them from the initial enablement so we can get the core support landed, and tackle them as separate series post-7.4.

Sure. Will drop these two.

Quoted 9 lines

As for actually landing this, the easiest thing at this point would probably be for me to grab the patches in a dedicated topic branch that's based off the kvm-x86/selftests branch at an appropriate point in time. Alternatively, I could provide a stable tag and someone else could grab the patches, but other than it being a little weird taking PPC changes through kvm-x86, that's by far the easiest approach since I'll be sending Paolo pull requests anyways and can explain the dependencies and whatnot.

TL;DR: what if you post a slightly trimmed-down v6 and I take it through kvm-x86?

Sure, Thanks a lot Sean!
Let me post v6 with the suggested approach.

-ritesh

#22 lore raw
Quoted 3 lines · Ritesh Harjani

Sean Christopherson <[email protected]> writes:
Also note - I will open code the TEST_GEN_PROGS_COMMON and will skip the kvm_create_max_vcpus

Oh, right, kvm_create_max_vcpus is a common test. Can userspace detect that it's running KVM-on-PowerVM (in a not completely unpleasant way)? If so, an alternative would be to keep the KVM_CAP_PPC_SMT change in v6 (patch 2) as a prep patch (before adding PPC support to Makefile.kvm), and then add a TEST_REQUIRE(!kvm_is_on_ppc_powervm()) or whatever.

I think I'd even prefer to take on an #ifdef (to scope it to PPC if necessary) over open coding TEST_GEN_PROGS_COMMON. LoongArch open coded its full test list for some reason, and in less than a year it has started missing out on new common tests.

Quoted 1 line

(& maybe few others like vm_types_test) from that in v6.

What's wrong with VM types test? That one really should Just Work on all architectures. It doesn't run on LoongArch, but I assume that's oversight?

#23 lore raw

Hi Sean,

Sorry I didn't see this email before sending out v6.
I think we can ignore v6, once the discussion here is sorted - I can share a v7.

Quoted 11 lines · Sean Christopherson
Quoted 3 lines · Ritesh Harjani

Sean Christopherson <[email protected]> writes:
Also note - I will open code the TEST_GEN_PROGS_COMMON and will skip the kvm_create_max_vcpus

Oh, right, kvm_create_max_vcpus is a common test. Can userspace detect that it's running KVM-on-PowerVM (in a not completely unpleasant way)? If so, an alternative would be to keep the KVM_CAP_PPC_SMT change in v6 (patch 2) as a prep patch (before adding PPC support to Makefile.kvm), and then add a TEST_REQUIRE(!kvm_is_on_ppc_powervm()) or whatever.

So stictly speaking there is no simple check like that - however, I think we can skip the test when we are running on pseries LPAR (meaning trying to run a nested guest). We already have the check is_pseries_lpar() for access_tracking_perf_test. I think we can re-use the same check here as well.

Quoted 2 lines

I think I'd even prefer to take on an #ifdef (to scope it to PPC if necessary) over open coding TEST_GEN_PROGS_COMMON.

Sure, so will add this check for kvm_create_max_vcpus()

#ifdef __powerpc64__
       TEST_REQUIRE(!is_pseries_lpar());

#endif

Actually I was thinking we may as well use the same check for now for skipping hardware_disable_test on pseries. Because there also we suffer from the same resource limitation. Let me know if that sounds ok to you or do you want us to skip kvm_create_max_vcpus() only for now, since it is part of TEST_GEN_PROGS_COMMON?

Quoted 9 lines

LoongArch open coded its full test list
for some reason, and in less than a year it has started missing out on new common tests.

Quoted 1 line

(& maybe few others like vm_types_test) from that in v6.

What's wrong with VM types test? That one really should Just Work on all architectures. It doesn't run on LoongArch, but I assume that's oversight?

So the test doesn't fail (it gets skipped). However this cap "KVM_CAP_VM_TYPES" is only supported on x86 and since I was planning to open code all common tests, hence I thought I may as well not add this in the first place.

BTW, based on this discussion, I think I will re-arrange the patches in the following order and send a v7. (The Makefile.kvm changes will only get added after the main patch which adds powerpc support).

cfabdb049bd7 2026-10-05 [Ritesh Harjani (IBM)] (HEAD -> feat-ppc-kvm-selftests-new-sean-v7) KVM: selftests: Skip hardware_disable_test on pseries 2b51fab87b95 2026-09-22 [Ritesh Harjani (IBM)] KVM: PPC: selftests: Skip idle-page check when running nested on pseries LPAR f5d1de1be4e9 2026-10-05 [Ritesh Harjani (IBM)] KVM: selftests: Skip kvm_create_max_vcpus on pseries
e45ba15cea25 2026-10-03 [Ritesh Harjani (IBM)] KVM: PPC: selftests: Add helper for checking if running nested 178c9bca0e20 2026-09-22 [Nicholas Piggin] KVM: PPC: selftests: add support for powerpc
22320662e776 2026-09-11 [Ritesh Harjani (IBM)] KVM: selftests: Fix kvm_create_max_vcpus test for powerpc
11b5712b213b 2026-09-22 [Ritesh Harjani (IBM)] KVM: selftests: Move memslot_perf_test off the 256M ELF load address 63c900860b5f 2026-09-22 [Ritesh Harjani (IBM)] KVM: selftests: Don't limit LE dirty-bitmap bitops to s390x

Please let me know if this sounds ok?

-ritesh

#24 lore raw
Quoted 8 lines · Ritesh Harjani

I think I'd even prefer to take on an #ifdef (to scope it to PPC if necessary)

Quoted 1 line

over open coding TEST_GEN_PROGS_COMMON.

Sure, so will add this check for kvm_create_max_vcpus()

#ifdef __powerpc64__
       TEST_REQUIRE(!is_pseries_lpar());

#endif

Or maybe to avoid too many ifdefs, something like:

  static inline kvm_is_ppc_pseries_lpar(void)
  {
          /*
           * Comment about how this setup has unique limitations and isn't
           * compatible with tests that create many VMs and/or vCPUs.
           */
  #ifdef __powerpc64___
          return !access("/proc/device-tree/rtas/ibm,hypertas-functions", F_OK);
  #else
          return false;
  #endif
  }

Probably redundant naming to some extent, but having "ppc" in there would make it super obvious it's a PPC-only check.

Quoted 12 lines

Actually I was thinking we may as well use the same check for now for skipping hardware_disable_test on pseries. Because there also we suffer from the same resource limitation. Let me know if that sounds ok to you or do you want us to skip kvm_create_max_vcpus() only for now, since it is part of TEST_GEN_PROGS_COMMON?

Quoted 6 lines

LoongArch open coded its full test list
for some reason, and in less than a year it has started missing out on new common tests.

Quoted 1 line

(& maybe few others like vm_types_test) from that in v6.

Quoted 8 lines
Quoted 3 lines

What's wrong with VM types test? That one really should Just Work on all architectures. It doesn't run on LoongArch, but I assume that's oversight?

So the test doesn't fail (it gets skipped). However this cap "KVM_CAP_VM_TYPES" is only supported on x86 and since I was planning to open code all common tests, hence I thought I may as well not add this in the first place.

/facepalm

I completely forgot KVM_CAP_VM_TYPES is x86-only. FWIW, I'd still say use TEST_GEN_PROGS_COMMON if possible.

Quoted 8 lines

BTW, based on this discussion, I think I will re-arrange the patches in the following order and send a v7. (The Makefile.kvm changes will only get added after the main patch which adds powerpc support).

cfabdb049bd7 2026-10-05 [Ritesh Harjani (IBM)] (HEAD -> feat-ppc-kvm-selftests-new-sean-v7) KVM: selftests: Skip hardware_disable_test on pseries 2b51fab87b95 2026-09-22 [Ritesh Harjani (IBM)] KVM: PPC: selftests: Skip idle-page check when running nested on pseries LPAR f5d1de1be4e9 2026-10-05 [Ritesh Harjani (IBM)] KVM: selftests: Skip kvm_create_max_vcpus on pseries
e45ba15cea25 2026-10-03 [Ritesh Harjani (IBM)] KVM: PPC: selftests: Add helper for checking if running nested

Doesn't this one need to come first? Or is this different than pseries LPAR?

Quoted 2 lines

178c9bca0e20 2026-09-22 [Nicholas Piggin] KVM: PPC: selftests: add support for powerpc 22320662e776 2026-09-11 [Ritesh Harjani (IBM)] KVM: selftests: Fix kvm_create_max_vcpus test for powerpc

This should come before "add support for powerpc", and should have a shortlog more like "Skip max vCPU IDs test on PPC with <whatever is a good description of the SMT cap>"

Quoted 5 lines

11b5712b213b 2026-09-22 [Ritesh Harjani (IBM)] KVM: selftests: Move memslot_perf_test off the 256M ELF load address 63c900860b5f 2026-09-22 [Ritesh Harjani (IBM)] KVM: selftests: Don't limit LE dirty-bitmap bitops to s390x

Please let me know if this sounds ok?

Ya, works for me!

#25 lore raw
Quoted 25 lines · Sean Christopherson
Quoted 8 lines · Ritesh Harjani

I think I'd even prefer to take on an #ifdef (to scope it to PPC if necessary)

Quoted 1 line

over open coding TEST_GEN_PROGS_COMMON.

Sure, so will add this check for kvm_create_max_vcpus()

#ifdef __powerpc64__
       TEST_REQUIRE(!is_pseries_lpar());

#endif

Or maybe to avoid too many ifdefs, something like:

  static inline kvm_is_ppc_pseries_lpar(void)
  {
          /*
           * Comment about how this setup has unique limitations and isn't
           * compatible with tests that create many VMs and/or vCPUs.
           */
  #ifdef __powerpc64___
          return !access("/proc/device-tree/rtas/ibm,hypertas-functions", F_OK);
  #else
          return false;
  #endif
  }
Quoted 3 lines

Probably redundant naming to some extent, but having "ppc" in there would make it super obvious it's a PPC-only check.

Sure. So I will get this definition added into kvm_util.h header file.

Quoted 30 lines
Quoted 12 lines

Actually I was thinking we may as well use the same check for now for skipping hardware_disable_test on pseries. Because there also we suffer from the same resource limitation. Let me know if that sounds ok to you or do you want us to skip kvm_create_max_vcpus() only for now, since it is part of TEST_GEN_PROGS_COMMON?

Quoted 6 lines

LoongArch open coded its full test list
for some reason, and in less than a year it has started missing out on new common tests.

Quoted 1 line

(& maybe few others like vm_types_test) from that in v6.

Quoted 8 lines
Quoted 3 lines

What's wrong with VM types test? That one really should Just Work on all architectures. It doesn't run on LoongArch, but I assume that's oversight?

So the test doesn't fail (it gets skipped). However this cap "KVM_CAP_VM_TYPES" is only supported on x86 and since I was planning to open code all common tests, hence I thought I may as well not add this in the first place.

/facepalm

I completely forgot KVM_CAP_VM_TYPES is x86-only. FWIW, I'd still say use TEST_GEN_PROGS_COMMON if possible.

Quoted 4 lines

BTW, based on this discussion, I think I will re-arrange the patches in the following order and send a v7. (The Makefile.kvm changes will only get added after the main patch which adds powerpc support).

Quoted 7 lines
Quoted 4 lines

cfabdb049bd7 2026-10-05 [Ritesh Harjani (IBM)] (HEAD -> feat-ppc-kvm-selftests-new-sean-v7) KVM: selftests: Skip hardware_disable_test on pseries 2b51fab87b95 2026-09-22 [Ritesh Harjani (IBM)] KVM: PPC: selftests: Skip idle-page check when running nested on pseries LPAR f5d1de1be4e9 2026-10-05 [Ritesh Harjani (IBM)] KVM: selftests: Skip kvm_create_max_vcpus on pseries
e45ba15cea25 2026-10-03 [Ritesh Harjani (IBM)] KVM: PPC: selftests: Add helper for checking if running nested

Doesn't this one need to come first? Or is this different than pseries LPAR?

That is correct. The patches are in the reverse order taken from the output of: git log --oneline ...

Quoted 4 lines
Quoted 2 lines

178c9bca0e20 2026-09-22 [Nicholas Piggin] KVM: PPC: selftests: add support for powerpc 22320662e776 2026-09-11 [Ritesh Harjani (IBM)] KVM: selftests: Fix kvm_create_max_vcpus test for powerpc

This should come before "add support for powerpc", and should have a shortlog

That is correct. The patches are in the reverse order taken from the output of: git log --oneline ...

Quoted 2 lines

more like "Skip max vCPU IDs test on PPC with <whatever is a good description of the SMT cap>"

Sure, I will change this to something like:

KVM: selftests: Skip the max vCPU ID test when KVM_CAP_PPC_SMT is set

kvm_create_max_vcpus creates vCPUs from 0..MAX_VCPUS-1, then again with ids at the top of KVM_CAP_MAX_VCPU_ID.

On PowerPC the vCPU id is not a flat index: it encodes SMT thread plus core. So on powerpc maximum permitted vCPU ID depends on the VM's SMT mode and the maximum reported by KVM_CAP_MAX_VCPU_ID exceeds a simple non-SMT VM's limit.

So, skip that second loop when KVM_CAP_PPC_SMT is non-zero. The cap is 0 on other arches, so they still run it. The 0..MAX_VCPUS pass is unchanged.

Quoted 7 lines
Quoted 5 lines

11b5712b213b 2026-09-22 [Ritesh Harjani (IBM)] KVM: selftests: Move memslot_perf_test off the 256M ELF load address 63c900860b5f 2026-09-22 [Ritesh Harjani (IBM)] KVM: selftests: Don't limit LE dirty-bitmap bitops to s390x

Please let me know if this sounds ok?

Ya, works for me!

Thanks! Will send v7 shortly with the discussed changes.

-ritesh

Tested-by on the v5 series
#26 lore raw
In reply to Ritesh Harjani (IBM)
Quoted 90 lines · Ritesh Harjani (IBM)

Patch v4 -> v5:
==============
- Fixed the issues reported by Anushree while running on kvm on powervm (nested).
- Fixed memslot_perf_test on powerpc.

PATCH v3 -> PATCH v4:
==================
- Rebased on top of Sean's new page allocator patch series v2 [1] This allowed to drop and patch-2 since it will now come from Sean's v2.
- Addressed review comments from Sean - squashed patches 6-10 in patch-1 of this.
- Dropped patch-5 to print vcpu_id when KVM_CREATE_VCPU ioctl fails.
- Added additional patch-3 to this series to allow dirty_log_test to run on all big-endian machines.

[1]: https://lore.kernel.org/kvm/[email protected]/
[v3]: https://lore.kernel.org/linuxppc-dev/2d2c46be7f051c7f1c645afaec67f57067d37a81.1781093720.git.ritesh.list@gmail.com/

Testing updates:
================
I have done some fair amount of testing of the selftests both on real HW and using various combinations on qemu (powernv+LE (default), pseries+cap-nested-hv, pseries+cap-nested-papr, powernv+BE). There were few powerpc kvm kernel fixes which were identified as part of this work. I will send those patches separately as those anyway needs to go in separately.

<pasted snippet of cover letter from previous versions>
=======================================================

Hi All,

This series primarly adds KVM selftests support for powerpc (64-bit, BookS, radix MMU).

This patch series is originally Nick's work. I have mainly only rebased it on the latest upstream tree. Since the rebase required few changes to all the four patches (Patch 1-4), I have dropped the earlier Acked-by from Michael Ellerman.

Since the last series was posted three years ago [1], I am resetting the version to RFC. This rebase was done as part of a larger effort to improve the selftests infrastructure for Linux on PowerPC tree. Thanks to Harsh and Maddy for their help on this.

Nicholas Piggin (1):
KVM: PPC: selftests: add support for powerpc

Ritesh Harjani (IBM) (8):
KVM: selftests: Enable kvm_create_max_vcpus test for powerpc
KVM: selftests: Don't limit LE dirty-bitmap bitops to s390x
KVM: selftests: Split out a KVM_CREATE_VCPU helper that can fail
KVM: selftests: Make kvm_create_max_vcpus tolerate ENOMEM
KVM: selftests: Limit the number of VM creates in hardware_disable_test
KVM: PPC: selftests: Make nested case on pseries LPARs as resource constrained
KVM: PPC: selftests: Skip idle-page check when running nested on pseries LPAR
KVM: selftests: Move memslot_perf_test off the 256M ELF load address

  MAINTAINERS                                   |   2 +
  tools/testing/selftests/kvm/Makefile          |   2 +-
  tools/testing/selftests/kvm/Makefile.kvm      |  10 +
  .../selftests/kvm/access_tracking_perf_test.c |  11 +
  tools/testing/selftests/kvm/dirty_log_test.c  |  12 +-
  .../selftests/kvm/hardware_disable_test.c     |   7 +-
  .../testing/selftests/kvm/include/kvm_util.h  |  13 +
  .../selftests/kvm/include/powerpc/hcall.h     |  17 +
  .../kvm/include/powerpc/kvm_util_arch.h       |  22 +
  .../selftests/kvm/include/powerpc/ppc_asm.h   |  32 ++
  .../selftests/kvm/include/powerpc/processor.h |  46 ++
  .../selftests/kvm/include/powerpc/ucall.h     |  21 +
  .../selftests/kvm/kvm_create_max_vcpus.c      |  29 +-
  tools/testing/selftests/kvm/lib/guest_modes.c |  20 +-
  tools/testing/selftests/kvm/lib/kvm_util.c    |  39 +-
  .../selftests/kvm/lib/powerpc/handlers.S      |  93 ++++
  .../testing/selftests/kvm/lib/powerpc/hcall.c |  45 ++
  .../selftests/kvm/lib/powerpc/processor.c     | 522 ++++++++++++++++++
  .../testing/selftests/kvm/lib/powerpc/ucall.c |  22 +
  .../testing/selftests/kvm/memslot_perf_test.c |   2 +-
  20 files changed, 942 insertions(+), 25 deletions(-)

create mode 100644 tools/testing/selftests/kvm/include/powerpc/hcall.h create mode 100644 tools/testing/selftests/kvm/include/powerpc/kvm_util_arch.h create mode 100644 tools/testing/selftests/kvm/include/powerpc/ppc_asm.h create mode 100644 tools/testing/selftests/kvm/include/powerpc/processor.h create mode 100644 tools/testing/selftests/kvm/include/powerpc/ucall.h create mode 100644 tools/testing/selftests/kvm/lib/powerpc/handlers.S create mode 100644 tools/testing/selftests/kvm/lib/powerpc/hcall.c create mode 100644 tools/testing/selftests/kvm/lib/powerpc/processor.c create mode 100644 tools/testing/selftests/kvm/lib/powerpc/ucall.c

Quoted 4 lines

--
2.39.5

Hi Ritesh,
Thanks for working on the fixes, I tested this series (v5) on top of Sean's pre-enabling series (v2) [1] on two real PowerPC systems. All patches applied cleanly and the tests
work correctly on both PowerVM LPAR and PowerNV bare-metal.

[1]: https://lore.kernel.org/kvm/[email protected]/

Full test suite summary (make run_tests):
-----------------------------------------
                                   LPAR    bare-metal demand_paging_test               PASS      PASS dirty_log_test                   PASS      PASS dirty_log_perf_test              PASS      PASS guest_print_test                 PASS      PASS hardware_disable_test            PASS      PASS kvm_binary_stats_test            PASS      PASS kvm_create_max_vcpus             PASS      PASS kvm_page_table_test              PASS      PASS set_memory_region_test           PASS      PASS memslot_modification_stress_test PASS      PASS memslot_perf_test                PASS      PASS access_tracking_perf_test        PASS      PASS irqfd_test                       SKIP      SKIP vm_types_test                    SKIP      SKIP
  --------------------------------------------------
  Total                         12 PASS   12 PASS 2 SKIP    2 SKIP

Per-patch validation:
---------------------
Patch 1 [KVM: PPC: selftests: add support for powerpc] All 14 tests built and ran successfully on PowerPC — the core infrastructure (lib/powerpc/processor.c, handlers.S, ucall.c, hcall.c) works correctly on both systems.

Patch 2 [KVM: selftests: Enable kvm_create_max_vcpus test for powerpc] kvm_create_max_vcpus ran successfully on both systems.

Patch 3 [KVM: selftests: Don't limit LE dirty-bitmap bitops to s390x] dirty_log_test ran successfully on both systems for both 4K and 64K page modes (big-endian dirty-bitmap bitops working correctly).

Patch 4 [KVM: selftests: Split out a KVM_CREATE_VCPU helper that can fail] KVM_CREATE_VCPU helper exercised by kvm_create_max_vcpus on both systems — clean failure path confirmed on LPAR (ENOMEM at vCPU 72).

Patch 5 [KVM: selftests: Make kvm_create_max_vcpus tolerate ENOMEM] LPAR:       Created 72 vCPUs before ENOMEM at id 72 — test completed gracefully without crash or assert.
  bare-metal: Successfully created all 2048 vCPUs — no ENOMEM hit.

Patch 6 [KVM: selftests: Limit the number of VM creates in hardware_disable_test] hardware_disable_test ran successfully on both systems without hitting OOM — VM create limiting working correctly on LPAR.

Patch 7 [KVM: PPC: selftests: Make nested case on pseries LPARs as resource constrained] access_tracking_perf_test correctly identified the LPAR as a resource-constrained nested environment and adjusted accordingly.

Patch 8 [KVM: PPC: selftests: Skip idle-page check when running nested on pseries LPAR] LPAR:
    Skipping idle page count sanity check, because the test is run nested [idle-page check correctly skipped on nested pseries LPAR] bare-metal:
    [No skip message — idle-page sanity check ran in full on PowerNV]

Patch 9 [KVM: selftests: Move memslot_perf_test off the 256M ELF load address] memslot_perf_test ran successfully on both systems — ELF load address conflict with PPC's 256M region resolved correctly.

Notes on SKIPs:
---------------
  - irqfd_test:   PowerPC has no in-kernel irqchip.
                  1..0 # SKIP - Requirement not met: kvm_arch_has_default_irqchip() Pre-existing, unrelated to this series.

  - vm_types_test: KVM_CAP_VM_TYPES is x86-only (SEV-SNP/TDX).
                  1..0 # SKIP - Requirement not met: kvm_has_cap(KVM_CAP_VM_TYPES) Pre-existing, unrelated to this series.

Please feel free to add :

Thank you,
Anushree Mathur