KVM: selftests: add powerpc support
Subsystems (3)
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
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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 ) +{ + asmvolatile ("" :::"memory" ); +} + +#endif
tools/testing/selftests/kvm/include/powerpc/ucall.h new file +21 -0
@@ -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
@@ -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
@@ -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
@@ -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, ®s); +if (regs.gpr[4 ] ==UCALL_R4_UCALL ) +return (void *)regs.gpr[5 ]; + } +return NULL ; +}
Signature · 1 line
2.39.5
[email protected]
AI reviewRe: [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
[ ... ]
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
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 inex_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[ ... ]
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 invirt_handle_interruptintentionally 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_regsstructure 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, doeshandle_interruptskip saving %r1 and %r2 into theex_regsstructure 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
Sean Christopherson
reviewerRe: [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.cMAINTAINERS +0
-0
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?
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.cMAINTAINERS +0
-0MAINTAINERS 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
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
@@ -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
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)
--- 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
@@ -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
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
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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
Sean Christopherson
reviewerRe: [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@@ -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().
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@@ -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_SMTthing 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 enableKVM_CAP_PPC_SMTand do the proper striding? Eating-ENOMEMis 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
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
@@ -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 2000static 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
Sean Christopherson
reviewerRe: [PATCH v5 6/9] KVM: selftests: Limit the number of VM creates in hardware_disable_test
Quoted 4 lines · Ritesh Harjani (IBM)
hardware_disable_testforks 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 whenkvm_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?
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_testforks 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 whenkvm_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
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
@@ -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
@@ -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
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
@@ -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
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
@@ -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
Sean Christopherson
reviewerRe: [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 at0x10000000(256M) which is also theMEM_GPA, so the identity map trips with the error:
PTE already present at level: 4 gva:0x10000000pte:0xc00000000002018fPut 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.
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
Sean Christopherson
reviewerQuoted 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?
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_testandhardware_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 thekvm_create_max_vcpuschanges, 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_vcpusandhardware_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
Sean Christopherson
reviewerQuoted 3 lines · Ritesh Harjani
Sean Christopherson <[email protected]> writes:
Also note - I will open code theTEST_GEN_PROGS_COMMONand will skip thekvm_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?
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 theTEST_GEN_PROGS_COMMONand will skip thekvm_create_max_vcpusOh, right,
kvm_create_max_vcpusis 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 theKVM_CAP_PPC_SMTchange 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 pseriese45ba15cea25 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 powerpc22320662e776 2026-09-11 [Ritesh Harjani (IBM)] KVM: selftests: Fix kvm_create_max_vcpus test for powerpc11b5712b213b 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
Sean Christopherson
reviewerQuoted 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_teston 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 skipkvm_create_max_vcpus()only for now, since it is part ofTEST_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).
cfabdb049bd72026-10-05 [Ritesh Harjani (IBM)] (HEAD -> feat-ppc-kvm-selftests-new-sean-v7) KVM: selftests: Skiphardware_disable_teston pseries2b51fab87b952026-09-22 [Ritesh Harjani (IBM)] KVM: PPC: selftests: Skip idle-page check when running nested on pseries LPARf5d1de1be4e92026-10-05 [Ritesh Harjani (IBM)] KVM: selftests: Skipkvm_create_max_vcpuson pseriese45ba15cea252026-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
178c9bca0e202026-09-22 [Nicholas Piggin] KVM: PPC: selftests: add support for powerpc22320662e7762026-09-11 [Ritesh Harjani (IBM)] KVM: selftests: Fixkvm_create_max_vcpustest 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
11b5712b213b2026-09-22 [Ritesh Harjani (IBM)] KVM: selftests: Movememslot_perf_testoff the 256M ELF load address63c900860b5f2026-09-22 [Ritesh Harjani (IBM)] KVM: selftests: Don't limit LE dirty-bitmap bitops to s390xPlease let me know if this sounds ok?
Ya, works for me!
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_teston 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 skipkvm_create_max_vcpus()only for now, since it is part ofTEST_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_TYPESis x86-only. FWIW, I'd still say useTEST_GEN_PROGS_COMMONif 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
cfabdb049bd72026-10-05 [Ritesh Harjani (IBM)] (HEAD -> feat-ppc-kvm-selftests-new-sean-v7) KVM: selftests: Skiphardware_disable_teston pseries2b51fab87b952026-09-22 [Ritesh Harjani (IBM)] KVM: PPC: selftests: Skip idle-page check when running nested on pseries LPARf5d1de1be4e92026-10-05 [Ritesh Harjani (IBM)] KVM: selftests: Skipkvm_create_max_vcpuson pseriese45ba15cea252026-10-03 [Ritesh Harjani (IBM)] KVM: PPC: selftests: Add helper for checking if running nestedDoesn'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
178c9bca0e202026-09-22 [Nicholas Piggin] KVM: PPC: selftests: add support for powerpc22320662e7762026-09-11 [Ritesh Harjani (IBM)] KVM: selftests: Fixkvm_create_max_vcpustest for powerpcThis 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
11b5712b213b2026-09-22 [Ritesh Harjani (IBM)] KVM: selftests: Movememslot_perf_testoff the 256M ELF load address63c900860b5f2026-09-22 [Ritesh Harjani (IBM)] KVM: selftests: Don't limit LE dirty-bitmap bitops to s390xPlease let me know if this sounds ok?
Ya, works for me!
Thanks! Will send v7 shortly with the discussed changes.
-ritesh
Quoted 90 lines · Ritesh Harjani (IBM)
Patch v4 -> v5:
==============
- Fixed the issues reported by Anushree while running on kvm on powervm (nested).
- Fixedmemslot_perf_teston 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 printvcpu_idwhenKVM_CREATE_VCPUioctl fails.
- Added additional patch-3 to this series to allowdirty_log_testto 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 powerpcRitesh Harjani (IBM) (8):
KVM: selftests: Enablekvm_create_max_vcpustest for powerpc
KVM: selftests: Don't limit LE dirty-bitmap bitops to s390x
KVM: selftests: Split out aKVM_CREATE_VCPUhelper that can fail
KVM: selftests: Makekvm_create_max_vcpustolerate ENOMEM
KVM: selftests: Limit the number of VM creates inhardware_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: Movememslot_perf_testoff the 256M ELF load addressMAINTAINERS | 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.hcreate mode 100644tools/testing/selftests/kvm/include/powerpc/kvm_util_arch.hcreate mode 100644tools/testing/selftests/kvm/include/powerpc/ppc_asm.hcreate mode 100644tools/testing/selftests/kvm/include/powerpc/processor.hcreate mode 100644tools/testing/selftests/kvm/include/powerpc/ucall.hcreate mode 100644tools/testing/selftests/kvm/lib/powerpc/handlers.Screate mode 100644tools/testing/selftests/kvm/lib/powerpc/hcall.ccreate mode 100644tools/testing/selftests/kvm/lib/powerpc/processor.ccreate mode 100644tools/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