KVM selftests for s390x
cover KVM selftests for s390x
This patch series enables the KVM selftests for s390x. As a first test, the sync_regs from x86 has been adapted to s390x, and after a fix for KVM_CAP_MAX_VCPU_ID on s390x, the kvm_create_max_vcpus is now enabled here, too.
Please note that the ucall() interface is not used yet - since s390x neither has PIO nor MMIO, this needs some more work first before it becomes usable (we likely should use a DIAG hypercall here, which is what the sync_reg test is currently using, too... I started working on that topic, but did not finish that work yet, so I decided to not include it yet).
RFC -> v1:
- Rebase, needed to add the first patch for vcpu_nested_state_get/set
- Added patch to introduce VM_MODE_DEFAULT macro
- Improved/cleaned up the code in processor.c
- Added patch to fix KVM_CAP_MAX_VCPU_ID on s390x
- Added patch to enable the kvm_create_max_vcpus on s390x and aarch64
Andrew Jones (1):
kvm: selftests: aarch64: fix default vm mode
Thomas Huth (8):
KVM: selftests: Wrap vcpu_nested_state_get/set functions with x86
guard
KVM: selftests: Guard struct kvm_vcpu_events with
__KVM_HAVE_VCPU_EVENTS
KVM: selftests: Introduce a VM_MODE_DEFAULT macro for the default bits
KVM: selftests: Align memory region addresses to 1M on s390x
KVM: selftests: Add processor code for s390x
KVM: selftests: Add the sync_regs test for s390x
KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
KVM: selftests: Move kvm_create_max_vcpus test to generic code
MAINTAINERS | 2 +
arch/mips/kvm/mips.c | 3 +
arch/powerpc/kvm/powerpc.c | 3 +
arch/s390/kvm/kvm-s390.c | 1 +
arch/x86/kvm/x86.c | 3 +
tools/testing/selftests/kvm/Makefile | 7 +-
.../testing/selftests/kvm/include/kvm_util.h | 10 +
.../selftests/kvm/include/s390x/processor.h | 22 ++
.../kvm/{x86_64 => }/kvm_create_max_vcpus.c | 3 +-
.../selftests/kvm/lib/aarch64/processor.c | 2 +-
tools/testing/selftests/kvm/lib/kvm_util.c | 25 +-
.../selftests/kvm/lib/s390x/processor.c | 286 ++++++++++++++++++
.../selftests/kvm/lib/x86_64/processor.c | 2 +-
.../selftests/kvm/s390x/sync_regs_test.c | 151 +++++++++
virt/kvm/arm/arm.c | 3 +
virt/kvm/kvm_main.c | 2 -
16 files changed, 514 insertions(+), 11 deletions(-)
create mode 100644 tools/testing/selftests/kvm/include/s390x/processor.h
rename tools/testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c (93%)
create mode 100644 tools/testing/selftests/kvm/lib/s390x/processor.c
create mode 100644 tools/testing/selftests/kvm/s390x/sync_regs_test.cSignature · 1 line
2.21.0
PATCH 1/9 KVM: selftests: Wrap vcpu_nested_state_get/set functions with x86 guard
struct kvm_nested_state is only available on x86 so far. To be able to compile the code on other architectures as well, we need to wrap the related code with #ifdefs.
--- tools/testing/selftests/kvm/include/kvm_util.h | 2 ++ tools/testing/selftests/kvm/lib/kvm_util.c | 2 ++ 2 files changed, 4 insertions(+)
tools/testing/selftests/kvm/include/kvm_util.h +2 -0
@@ -118,10 +118,12 @@ void vcpu_events_get(struct kvm_vm *vm, uint32_t vcpuid, struct kvm_vcpu_events *events);void vcpu_events_set (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_vcpu_events *events); +#ifdef __x86_64__void vcpu_nested_state_get (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_nested_state *state);int vcpu_nested_state_set (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_nested_state *state,bool ignore_error); +#endif const char *exit_reason_str (unsigned int exit_reason);
tools/testing/selftests/kvm/lib/kvm_util.c +2 -0
@@ -1250,6 +1250,7 @@ void vcpu_events_set(struct kvm_vm *vm, uint32_t vcpuid, ret, errno); } +#ifdef __x86_64__void vcpu_nested_state_get (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_nested_state *state) {
@@ -1281,6 +1282,7 @@ int vcpu_nested_state_set(struct kvm_vm *vm, uint32_t vcpuid, return ret; } +#endif /* * VM VCPU System Regs Get
Signature · 1 line
2.21.0
PATCH 2/9 KVM: selftests: Guard struct kvm_vcpu_events with __KVM_HAVE_VCPU_EVENTS
In reply to Thomas HuthThe struct kvm_vcpu_events code is only available on certain architectures (arm, arm64 and x86). To be able to compile kvm_util.c also for other architectures, we have to fence the code with __KVM_HAVE_VCPU_EVENTS.
--- tools/testing/selftests/kvm/include/kvm_util.h | 2 ++ tools/testing/selftests/kvm/lib/kvm_util.c | 2 ++ 2 files changed, 4 insertions(+)
tools/testing/selftests/kvm/include/kvm_util.h +2 -0
@@ -114,10 +114,12 @@ void vcpu_sregs_set(struct kvm_vm *vm, uint32_t vcpuid, struct kvm_sregs *sregs);int _vcpu_sregs_set (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_sregs *sregs); +#ifdef __KVM_HAVE_VCPU_EVENTSvoid vcpu_events_get (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_vcpu_events *events);void vcpu_events_set (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_vcpu_events *events); +#endif #ifdef __x86_64__void vcpu_nested_state_get (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_nested_state *state);
tools/testing/selftests/kvm/lib/kvm_util.c +2 -0
@@ -1224,6 +1224,7 @@ void vcpu_regs_set(struct kvm_vm *vm, uint32_t vcpuid, struct kvm_regs *regs) ret, errno); } +#ifdef __KVM_HAVE_VCPU_EVENTSvoid vcpu_events_get (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_vcpu_events *events) {
@@ -1249,6 +1250,7 @@ void vcpu_events_set(struct kvm_vm *vm, uint32_t vcpuid,TEST_ASSERT (ret ==0 ,"KVM_SET_VCPU_EVENTS, failed, rc: %i errno: %i" , ret, errno); } +#endif #ifdef __x86_64__ void vcpu_nested_state_get(struct kvm_vm *vm, uint32_t vcpuid,
Signature · 1 line
2.21.0
Re: [PATCH 2/9] KVM: selftests: Guard struct kvm_vcpu_events with __KVM_HAVE_VCPU_EVENTS
Quoted 51 lines · Thomas Huth
The struct
kvm_vcpu_eventscode is only available on certain architectures (arm, arm64 and x86). To be able to compilekvm_util.calso for other architectures, we have to fence the code with__KVM_HAVE_VCPU_EVENTS.Reviewed-by David Hildenbrand <david at redhat.com>Signed-off-by Thomas Huth <thuth at redhat.com>--- tools/testing/selftests/kvm/include/kvm_util.h | 2 ++ tools/testing/selftests/kvm/lib/kvm_util.c | 2 ++ 2 files changed, 4 insertions(+)tools/testing/selftests/kvm/include/kvm_util.h +2
-0@@ -114,10 +114,12 @@ void vcpu_sregs_set(struct kvm_vm *vm, uint32_t vcpuid, struct kvm_sregs *sregs);int _vcpu_sregs_set (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_sregs *sregs); +#ifdef __KVM_HAVE_VCPU_EVENTSvoid vcpu_events_get (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_vcpu_events *events);void vcpu_events_set (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_vcpu_events *events); +#endif #ifdef __x86_64__void vcpu_nested_state_get (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_nested_state *state);tools/testing/selftests/kvm/lib/kvm_util.c +2
-0@@ -1224,6 +1224,7 @@ void vcpu_regs_set(struct kvm_vm *vm, uint32_t vcpuid, struct kvm_regs *regs) ret, errno); } +#ifdef __KVM_HAVE_VCPU_EVENTSvoid vcpu_events_get (struct kvm_vm *vm,uint32_t vcpuid,struct kvm_vcpu_events *events) {@@ -1249,6 +1250,7 @@ void vcpu_events_set(struct kvm_vm *vm, uint32_t vcpuid,TEST_ASSERT (ret ==0 ,"KVM_SET_VCPU_EVENTS, failed, rc: %i errno: %i" , ret, errno); } +#endif #ifdef __x86_64__ void vcpu_nested_state_get(struct kvm_vm *vm, uint32_t vcpuid,Signature · 1 line
2.21.0
PATCH 3/9 kvm: selftests: aarch64: fix default vm mode
In reply to Thomas HuthFrom: Andrew Jones <[email protected]>
VM_MODE_P52V48_4K is not a valid mode for AArch64. Replace its use in vm_create_default() with a mode that works and represents a good AArch64 default. (We didn't ever see a problem with this because we don't have any unit tests using vm_create_default(), but it's good to get it fixed in advance.)
--- tools/testing/selftests/kvm/lib/aarch64/processor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/kvm/lib/aarch64/processor.c +1 -1
@@ -226,7 +226,7 @@ struct kvm_vm *vm_create_default(uint32_t vcpuid, uint64_t extra_mem_pages,uint64_t extra_pg_pages = (extra_mem_pages / ptrs_per_4k_pte) *2 ;struct kvm_vm *vm; - vm =vm_create (VM_MODE_P52V48_4K ,DEFAULT_GUEST_PHY_PAGES + extra_pg_pages,O_RDWR ); + vm =vm_create (VM_MODE_P40V48_4K ,DEFAULT_GUEST_PHY_PAGES + extra_pg_pages,O_RDWR );kvm_vm_elf_load (vm, program_invocation_name,0 ,0 );vm_vcpu_add_default (vm, vcpuid, guest_code);
Signature · 1 line
2.21.0
Re: [PATCH 3/9] kvm: selftests: aarch64: fix default vm mode
Quoted 10 lines · Thomas Huth
From: Andrew Jones <drjones at redhat.com>
VM_MODE_P52V48_4Kis not a valid mode for AArch64. Replace its use invm_create_default()with a mode that works and represents a good AArch64 default. (We didn't ever see a problem with this because we don't have any unit tests usingvm_create_default(), but it's good to get it fixed in advance.)Reported-by Thomas Huth <thuth at redhat.com>Signed-off-by Andrew Jones <drjones at redhat.com>
I will add Thomas Signed-off-by here as well.
Quoted 18 lines
--- tools/testing/selftests/kvm/lib/aarch64/processor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)tools/testing/selftests/kvm/lib/aarch64/processor.c +1
-1@@ -226,7 +226,7 @@ struct kvm_vm *vm_create_default(uint32_t vcpuid, uint64_t extra_mem_pages,uint64_t extra_pg_pages = (extra_mem_pages / ptrs_per_4k_pte) *2 ;struct kvm_vm *vm; - vm =vm_create (VM_MODE_P52V48_4K ,DEFAULT_GUEST_PHY_PAGES + extra_pg_pages,O_RDWR ); + vm =vm_create (VM_MODE_P40V48_4K ,DEFAULT_GUEST_PHY_PAGES + extra_pg_pages,O_RDWR );kvm_vm_elf_load (vm, program_invocation_name,0 ,0 );vm_vcpu_add_default (vm, vcpuid, guest_code);
PATCH 4/9 KVM: selftests: Introduce a VM_MODE_DEFAULT macro for the default bits
In reply to Thomas HuthThis will be required later for tests like the kvm_create_max_vcpus test that do not use the vm_create_default() function.
--- tools/testing/selftests/kvm/include/kvm_util.h | 6 ++++++ tools/testing/selftests/kvm/lib/aarch64/processor.c | 2 +- tools/testing/selftests/kvm/lib/x86_64/processor.c | 2 +- 3 files changed, 8 insertions(+), 2 deletions(-)
tools/testing/selftests/kvm/include/kvm_util.h +6 -0
@@ -43,6 +43,12 @@ enum vm_guest_mode { NUM_VM_MODES, }; +#ifdef __aarch64__ +#define VM_MODE_DEFAULT VM_MODE_P40V48_4K +#else +#define VM_MODE_DEFAULT VM_MODE_P52V48_4K +#endif +#define vm_guest_mode_string (m) vm_guest_mode_string[m]extern const char *const vm_guest_mode_string[];
tools/testing/selftests/kvm/lib/aarch64/processor.c +1 -1
@@ -226,7 +226,7 @@ struct kvm_vm *vm_create_default(uint32_t vcpuid, uint64_t extra_mem_pages,uint64_t extra_pg_pages = (extra_mem_pages / ptrs_per_4k_pte) *2 ;struct kvm_vm *vm; - vm =vm_create (VM_MODE_P40V48_4K ,DEFAULT_GUEST_PHY_PAGES + extra_pg_pages,O_RDWR ); + vm =vm_create (VM_MODE_DEFAULT ,DEFAULT_GUEST_PHY_PAGES + extra_pg_pages,O_RDWR );kvm_vm_elf_load (vm, program_invocation_name,0 ,0 );vm_vcpu_add_default (vm, vcpuid, guest_code);
tools/testing/selftests/kvm/lib/x86_64/processor.c +1 -1
@@ -823,7 +823,7 @@ struct kvm_vm *vm_create_default(uint32_t vcpuid, uint64_t extra_mem_pages,uint64_t extra_pg_pages = extra_mem_pages /512 *2 ;/* Create VM */ - vm =vm_create (VM_MODE_P52V48_4K , + vm =vm_create (VM_MODE_DEFAULT ,DEFAULT_GUEST_PHY_PAGES + extra_pg_pages,O_RDWR );
Signature · 1 line
2.21.0
Re: [PATCH 4/9] KVM: selftests: Introduce a VM_MODE_DEFAULT macro for the default bits
Quoted 56 lines · Thomas Huth
This will be required later for tests like the
kvm_create_max_vcpustest that do not use thevm_create_default()function.Signed-off-by Thomas Huth <thuth at redhat.com>--- tools/testing/selftests/kvm/include/kvm_util.h | 6 ++++++ tools/testing/selftests/kvm/lib/aarch64/processor.c | 2 +- tools/testing/selftests/kvm/lib/x86_64/processor.c | 2 +- 3 files changed, 8 insertions(+), 2 deletions(-)tools/testing/selftests/kvm/include/kvm_util.h +6
-0@@ -43,6 +43,12 @@ enum vm_guest_mode { NUM_VM_MODES, }; +#ifdef __aarch64__ +#define VM_MODE_DEFAULT VM_MODE_P40V48_4K +#else +#define VM_MODE_DEFAULT VM_MODE_P52V48_4K +#endif +#define vm_guest_mode_string (m) vm_guest_mode_string[m]extern const char *const vm_guest_mode_string[];tools/testing/selftests/kvm/lib/aarch64/processor.c +1
-1@@ -226,7 +226,7 @@ struct kvm_vm *vm_create_default(uint32_t vcpuid, uint64_t extra_mem_pages,uint64_t extra_pg_pages = (extra_mem_pages / ptrs_per_4k_pte) *2 ;struct kvm_vm *vm; - vm =vm_create (VM_MODE_P40V48_4K ,DEFAULT_GUEST_PHY_PAGES + extra_pg_pages,O_RDWR ); + vm =vm_create (VM_MODE_DEFAULT ,DEFAULT_GUEST_PHY_PAGES + extra_pg_pages,O_RDWR );kvm_vm_elf_load (vm, program_invocation_name,0 ,0 );vm_vcpu_add_default (vm, vcpuid, guest_code);tools/testing/selftests/kvm/lib/x86_64/processor.c +1
-1@@ -823,7 +823,7 @@ struct kvm_vm *vm_create_default(uint32_t vcpuid, uint64_t extra_mem_pages,uint64_t extra_pg_pages = extra_mem_pages /512 *2 ;/* Create VM */ - vm =vm_create (VM_MODE_P52V48_4K , + vm =vm_create (VM_MODE_DEFAULT ,DEFAULT_GUEST_PHY_PAGES + extra_pg_pages,O_RDWR );Signature · 1 line
2.21.0
PATCH 5/9 KVM: selftests: Align memory region addresses to 1M on s390x
In reply to Thomas HuthOn s390x, there is a constraint that memory regions have to be aligned to 1M (or running the VM will fail). Introduce a new "alignment" variable in the vm_userspace_mem_region_add() function which now can be used for both, huge page and s390x alignment requirements.
--- tools/testing/selftests/kvm/lib/kvm_util.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
tools/testing/selftests/kvm/lib/kvm_util.c +16 -5
@@ -559,6 +559,7 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,unsigned long pmem_size =0 ;struct userspace_mem_region *region;size_t huge_page_size =KVM_UTIL_PGS_PER_HUGEPG * vm->page_size; +size_t alignment;TEST_ASSERT ((guest_paddr % vm->page_size) ==0 ,"Guest physical " "address not on a page boundary.\n"
@@ -608,9 +609,20 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,TEST_ASSERT (region !=NULL ,"Insufficient Memory" ); region->mmap_size = npages * vm->page_size; -/* Enough memory to align up to a huge page. */ +#ifdef __s390x__ +/* On s390x, the host address must be aligned to 1M (due to PGSTEs) */ + alignment =0x100000 ; +#else + alignment =1 ; +#endif +if (src_type ==VM_MEM_SRC_ANONYMOUS_THP ) - region->mmap_size += huge_page_size; + alignment = huge_page_size; + +/* Add enough memory to align up if necessary */ +if (alignment >1 ) + region->mmap_size += alignment; + region->mmap_start =mmap (NULL , region->mmap_size,PROT_READ |PROT_WRITE , MAP_PRIVATE | MAP_ANONYMOUS
@@ -620,9 +632,8 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,"test_malloc failed, mmap_start: %p errno: %i" , region->mmap_start, errno); -/* Align THP allocation up to start of a huge page. */ - region->host_mem =align (region->mmap_start, - src_type ==VM_MEM_SRC_ANONYMOUS_THP ? huge_page_size :1 ); +/* Align host address */ + region->host_mem =align (region->mmap_start, alignment);/* As needed perform madvise */ if (src_type ==VM_MEM_SRC_ANONYMOUS || src_type ==VM_MEM_SRC_ANONYMOUS_THP ) {
Signature · 1 line
2.21.0
Re: [PATCH 5/9] KVM: selftests: Align memory region addresses to 1M on s390x
Quoted 27 lines · Thomas Huth
On s390x, there is a constraint that memory regions have to be aligned to 1M (or running the VM will fail). Introduce a new "alignment" variable in the
vm_userspace_mem_region_add()function which now can be used for both, huge page and s390x alignment requirements.Signed-off-by Thomas Huth <thuth at redhat.com>--- tools/testing/selftests/kvm/lib/kvm_util.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)tools/testing/selftests/kvm/lib/kvm_util.c +1
-1@@ -559,6 +559,7 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,unsigned long pmem_size =0 ;struct userspace_mem_region *region;size_t huge_page_size =KVM_UTIL_PGS_PER_HUGEPG * vm->page_size; +size_t alignment;TEST_ASSERT ((guest_paddr % vm->page_size) ==0 ,"Guest physical " "address not on a page boundary.\n"@@ -608,9 +609,20 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,TEST_ASSERT (region !=NULL ,"Insufficient Memory" ); region->mmap_size = npages * vm->page_size; -/* Enough memory to align up to a huge page. */
tools/testing/selftests/kvm/lib/kvm_util.c void vm_userspace_mem_region_add(struct kvm_vm *vm, · line 620
Quoted 10 lines
tools/testing/selftests/kvm/lib/kvm_util.c +8
-1+#ifdef __s390x__ +/* On s390x, the host address must be aligned to 1M (due to PGSTEs) */ + alignment =0x100000 ; +#else + alignment =1 ; +#endif +if (src_type ==VM_MEM_SRC_ANONYMOUS_THP ) - region->mmap_size += huge_page_size; + alignment = huge_page_size;
I guess s390x won't ever support VM_MEM_SRC_ANONYMOUS_THP? If it does, then we need 'alignment = max(huge_page_size, alignment)'. Actually that might be a nice way to write this anyway for future-proofing.
Quoted 23 lines
tools/testing/selftests/kvm/lib/kvm_util.c +7
-3+ +/* Add enough memory to align up if necessary */ +if (alignment >1 ) + region->mmap_size += alignment; + region->mmap_start =mmap (NULL , region->mmap_size,PROT_READ |PROT_WRITE , MAP_PRIVATE | MAP_ANONYMOUS@@ -620,9 +632,8 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,"test_malloc failed, mmap_start: %p errno: %i" , region->mmap_start, errno); -/* Align THP allocation up to start of a huge page. */ - region->host_mem =align (region->mmap_start, - src_type ==VM_MEM_SRC_ANONYMOUS_THP ? huge_page_size :1 ); +/* Align host address */ + region->host_mem =align (region->mmap_start, alignment);/* As needed perform madvise */ if (src_type ==VM_MEM_SRC_ANONYMOUS || src_type ==VM_MEM_SRC_ANONYMOUS_THP ) {Signature · 1 line
2.21.0
Re: Re: [PATCH 5/9] KVM: selftests: Align memory region addresses to 1M on s390x
Quoted 27 lines · Andrew Jones
Quoted 26 lines · Thomas Huth
On s390x, there is a constraint that memory regions have to be aligned to 1M (or running the VM will fail). Introduce a new "alignment" variable in the
vm_userspace_mem_region_add()function which now can be used for both, huge page and s390x alignment requirements.Signed-off-by Thomas Huth <thuth at redhat.com>--- tools/testing/selftests/kvm/lib/kvm_util.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)tools/testing/selftests/kvm/lib/kvm_util.c +1
-0@@ -559,6 +559,7 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,unsigned long pmem_size =0 ;struct userspace_mem_region *region;size_t huge_page_size =KVM_UTIL_PGS_PER_HUGEPG * vm->page_size; +size_t alignment;TEST_ASSERT ((guest_paddr % vm->page_size) ==0 ,"Guest physical " "address not on a page boundary.\n"@@ -608,9 +609,20 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,TEST_ASSERT (region !=NULL ,"Insufficient Memory" ); region->mmap_size = npages * vm->page_size;
Quoted 15 lines
tools/testing/selftests/kvm/lib/kvm_util.c void vm_userspace_mem_region_add(struct kvm_vm *vm, · line 620
Quoted 11 lines
tools/testing/selftests/kvm/lib/kvm_util.c +8
-2-/* Enough memory to align up to a huge page. */ +#ifdef __s390x__ +/* On s390x, the host address must be aligned to 1M (due to PGSTEs) */ + alignment =0x100000 ; +#else + alignment =1 ; +#endif +if (src_type ==VM_MEM_SRC_ANONYMOUS_THP ) - region->mmap_size += huge_page_size; + alignment = huge_page_size;I guess s390x won't ever support
VM_MEM_SRC_ANONYMOUS_THP? If it does, then we need 'alignment =max(huge_page_size, alignment)'. Actually that might be a nice way to write this anyway for future-proofing.
I can do
- alignment = huge_page_size;
+ alignment = max(huge_page_size, alignment);
when applying.
Quoted 25 lines
Quoted 24 lines
tools/testing/selftests/kvm/lib/kvm_util.c +7
-3+ +/* Add enough memory to align up if necessary */ +if (alignment >1 ) + region->mmap_size += alignment; + region->mmap_start =mmap (NULL , region->mmap_size,PROT_READ |PROT_WRITE , MAP_PRIVATE | MAP_ANONYMOUS@@ -620,9 +632,8 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,"test_malloc failed, mmap_start: %p errno: %i" , region->mmap_start, errno); -/* Align THP allocation up to start of a huge page. */ - region->host_mem =align (region->mmap_start, - src_type ==VM_MEM_SRC_ANONYMOUS_THP ? huge_page_size :1 ); +/* Align host address */ + region->host_mem =align (region->mmap_start, alignment);/* As needed perform madvise */ if (src_type ==VM_MEM_SRC_ANONYMOUS || src_type ==VM_MEM_SRC_ANONYMOUS_THP ) {Signature · 1 line
2.21.0
Re: [PATCH 5/9] KVM: selftests: Align memory region addresses to 1M on s390x
Quoted 50 lines · Christian Borntraeger
Quoted 27 lines · Andrew Jones
Quoted 26 lines · Thomas Huth
On s390x, there is a constraint that memory regions have to be aligned to 1M (or running the VM will fail). Introduce a new "alignment" variable in the
vm_userspace_mem_region_add()function which now can be used for both, huge page and s390x alignment requirements.Signed-off-by Thomas Huth <thuth at redhat.com>--- tools/testing/selftests/kvm/lib/kvm_util.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)tools/testing/selftests/kvm/lib/kvm_util.c +1
-0@@ -559,6 +559,7 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,unsigned long pmem_size =0 ;struct userspace_mem_region *region;size_t huge_page_size =KVM_UTIL_PGS_PER_HUGEPG * vm->page_size; +size_t alignment;TEST_ASSERT ((guest_paddr % vm->page_size) ==0 ,"Guest physical " "address not on a page boundary.\n"@@ -608,9 +609,20 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,TEST_ASSERT (region !=NULL ,"Insufficient Memory" ); region->mmap_size = npages * vm->page_size;Quoted 15 lines
tools/testing/selftests/kvm/lib/kvm_util.c void vm_userspace_mem_region_add(struct kvm_vm *vm, · line 620
Quoted 11 lines
tools/testing/selftests/kvm/lib/kvm_util.c +8
-2-/* Enough memory to align up to a huge page. */ +#ifdef __s390x__ +/* On s390x, the host address must be aligned to 1M (due to PGSTEs) */ + alignment =0x100000 ; +#else + alignment =1 ; +#endif +if (src_type ==VM_MEM_SRC_ANONYMOUS_THP ) - region->mmap_size += huge_page_size; + alignment = huge_page_size;I guess s390x won't ever support
VM_MEM_SRC_ANONYMOUS_THP? If it does, then we need 'alignment =max(huge_page_size, alignment)'. Actually that might be a nice way to write this anyway for future-proofing.I can do
(quoted diff) +1
-1- alignment = huge_page_size; + alignment = max(huge_page_size, alignment);
Quoted 1 line
when applying.
Yes, please, that's certainly cleaner this way.
Thanks,
Thomas
PATCH 6/9 KVM: selftests: Add processor code for s390x
In reply to Thomas HuthCode that takes care of basic CPU setup, page table walking, etc.
--- MAINTAINERS | 1 + tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/include/s390x/processor.h | 22 ++ .../selftests/kvm/lib/s390x/processor.c | 286 ++++++++++++++++++ 4 files changed, 310 insertions(+) create mode 100644 tools/testing/selftests/kvm/include/s390x/processor.h create mode 100644 tools/testing/selftests/kvm/lib/s390x/processor.c
MAINTAINERS +1 -0
@@ -8663,6 +8663,7 @@ F: arch/s390/include/asm/gmap.h F: arch/s390/include/asm/kvm* F: arch/s390/kvm/ F: arch/s390/mm/gmap.c +F: tools/testing/selftests/kvm/*/s390x/ KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86) M: Paolo Bonzini <pbonzini at redhat.com>
tools/testing/selftests/kvm/Makefile +1 -0
@@ -9,6 +9,7 @@ UNAME_M := $(shell uname -m) LIBKVM = lib/assert.c lib/elf.c lib/io.c lib/kvm_util.c lib/ucall.c lib/sparsebit.c LIBKVM_x86_64 = lib/x86_64/processor.c lib/x86_64/vmx.c LIBKVM_aarch64 = lib/aarch64/processor.c +LIBKVM_s390x = lib/s390x/processor.c TEST_GEN_PROGS_x86_64 = x86_64/platform_info_test TEST_GEN_PROGS_x86_64 += x86_64/set_sregs_test
tools/testing/selftests/kvm/include/s390x/processor.h new file +22 -0
@@ -0,0 +1,22 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* +* s390x processor specific defines +*/ +#ifndef SELFTEST_KVM_PROCESSOR_H +#define SELFTEST_KVM_PROCESSOR_H + +/* Bits in the region/segment table entry */ +#define REGION_ENTRY_ORIGIN ~0xfffUL/* region/segment table origin */ +#define REGION_ENTRY_PROTECT 0x200/* region protection bit */ +#define REGION_ENTRY_NOEXEC 0x100/* region no-execute bit */ +#define REGION_ENTRY_OFFSET 0xc0/* region table offset */ +#define REGION_ENTRY_INVALID 0x20/* invalid region table entry */ +#define REGION_ENTRY_TYPE 0x0c/* region/segment table type mask */ +#define REGION_ENTRY_LENGTH 0x03/* region third length */ + +/* Bits in the page table entry */ +#define PAGE_INVALID 0x400/* HW invalid bit */ +#define PAGE_PROTECT 0x200/* HW read-only bit */ +#define PAGE_NOEXEC 0x100/* HW no-execute bit */ + +#endif
tools/testing/selftests/kvm/lib/s390x/processor.c new file +286 -0
286 lines not on this page · raw message
Signature · 1 line
2.21.0
PATCH 7/9 KVM: selftests: Add the sync_regs test for s390x
In reply to Thomas HuthThe test is an adaption of the same test for x86. Note that there are some differences in the way how s390x deals with the kvm_valid_regs in struct kvm_run, so some of the tests had to be removed. Also this test is not using the ucall() interface on s390x yet (which would need some work to be usable on s390x), so it simply drops out of the VM with a diag 0x501 breakpoint instead.
--- MAINTAINERS | 1 + tools/testing/selftests/kvm/Makefile | 2 + .../selftests/kvm/s390x/sync_regs_test.c | 151 ++++++++++++++++++ 3 files changed, 154 insertions(+) create mode 100644 tools/testing/selftests/kvm/s390x/sync_regs_test.c
MAINTAINERS +1 -0
@@ -8663,6 +8663,7 @@ F: arch/s390/include/asm/gmap.h F: arch/s390/include/asm/kvm* F: arch/s390/kvm/ F: arch/s390/mm/gmap.c +F: tools/testing/selftests/kvm/s390x/ F: tools/testing/selftests/kvm/*/s390x/ KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)
tools/testing/selftests/kvm/Makefile +2 -0
@@ -29,6 +29,8 @@ TEST_GEN_PROGS_x86_64 += clear_dirty_log_test TEST_GEN_PROGS_aarch64 += dirty_log_test TEST_GEN_PROGS_aarch64 += clear_dirty_log_test +TEST_GEN_PROGS_s390x += s390x/sync_regs_test + TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(UNAME_M)) LIBKVM += $(LIBKVM_$(UNAME_M))
tools/testing/selftests/kvm/s390x/sync_regs_test.c new file +151 -0
151 lines not on this page · raw message
Signature · 1 line
2.21.0
PATCH 8/9 KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
In reply to Thomas HuthKVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all architectures. However, on s390x, the amount of usable CPUs is determined during runtime - it is depending on the features of the machine the code is running on. Since we are using the vcpu_id as an index into the SCA structures that are defined by the hardware (see e.g. the sca_add_vcpu() function), it is not only the amount of CPUs that is limited by the hard- ware, but also the range of IDs that we can use.
Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too. So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common code into the architecture specific code, and on s390x we have to return the same value here as for KVM_CAP_MAX_VCPUS.
This problem has been discovered with the kvm_create_max_vcpus selftest. With this change applied, the selftest now passes on s390x, too.
--- arch/mips/kvm/mips.c | 3 +++ arch/powerpc/kvm/powerpc.c | 3 +++ arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 +++ virt/kvm/arm/arm.c | 3 +++ virt/kvm/kvm_main.c | 2 -- 6 files changed, 13 insertions(+), 2 deletions(-)
arch/mips/kvm/mips.c +3 -0
@@ -1122,6 +1122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_MIPS_FPU :/* We don't handle systems with inconsistent cpu_has_fpu */ r = !!raw_cpu_has_fpu;
arch/powerpc/kvm/powerpc.c +3 -0
@@ -657,6 +657,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;#ifdef CONFIG_PPC_BOOK3S_64 case KVM_CAP_PPC_GET_SMMU_INFO : r =1 ;
arch/s390/kvm/kvm-s390.c +1 -0
@@ -539,6 +539,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)break ;case KVM_CAP_NR_VCPUS :case KVM_CAP_MAX_VCPUS : +case KVM_CAP_MAX_VCPU_ID : r =KVM_S390_BSCA_CPU_SLOTS ;if (!kvm_s390_use_sca_entries ()) r =KVM_MAX_VCPUS ;
arch/x86/kvm/x86.c +3 -0
@@ -3122,6 +3122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_PV_MMU :/* obsolete */ r =0 ;break ;
virt/kvm/arm/arm.c +3 -0
@@ -224,6 +224,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_MSI_DEVID :if (!kvm) r = -EINVAL ;
virt/kvm/kvm_main.c +0 -2
@@ -3146,8 +3146,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)case KVM_CAP_MULTI_ADDRESS_SPACE :return KVM_ADDRESS_SPACE_NUM ;#endif -case KVM_CAP_MAX_VCPU_ID : -return KVM_MAX_VCPU_ID ;case KVM_CAP_NR_MEMSLOTS :return KVM_USER_MEM_SLOTS ;default :
Signature · 1 line
2.21.0
Re: [PATCH 8/9] KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
Quoted 108 lines · Thomas Huth
KVM_CAP_MAX_VCPU_IDis currently always reportingKVM_MAX_VCPU_IDon all architectures. However, on s390x, the amount of usable CPUs is determined during runtime - it is depending on the features of the machine the code is running on. Since we are using thevcpu_idas an index into the SCA structures that are defined by the hardware (see e.g. thesca_add_vcpu()function), it is not only the amount of CPUs that is limited by the hard- ware, but also the range of IDs that we can use.
ThusKVM_CAP_MAX_VCPU_IDmust be determined during runtime on s390x, too. So the handling ofKVM_CAP_MAX_VCPU_IDhas to be moved from the common code into the architecture specific code, and on s390x we have to return the same value here as forKVM_CAP_MAX_VCPUS.
This problem has been discovered with thekvm_create_max_vcpusselftest. With this change applied, the selftest now passes on s390x, too.Signed-off-by Thomas Huth <thuth at redhat.com>--- arch/mips/kvm/mips.c | 3 +++ arch/powerpc/kvm/powerpc.c | 3 +++ arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 +++ virt/kvm/arm/arm.c | 3 +++ virt/kvm/kvm_main.c | 2 -- 6 files changed, 13 insertions(+), 2 deletions(-)arch/mips/kvm/mips.c +3
-0@@ -1122,6 +1122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_MIPS_FPU :/* We don't handle systems with inconsistent cpu_has_fpu */ r = !!raw_cpu_has_fpu;arch/powerpc/kvm/powerpc.c +3
-0@@ -657,6 +657,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;#ifdef CONFIG_PPC_BOOK3S_64 case KVM_CAP_PPC_GET_SMMU_INFO : r =1 ;arch/s390/kvm/kvm-s390.c +1
-0@@ -539,6 +539,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)break ;case KVM_CAP_NR_VCPUS :case KVM_CAP_MAX_VCPUS : +case KVM_CAP_MAX_VCPU_ID : r =KVM_S390_BSCA_CPU_SLOTS ;if (!kvm_s390_use_sca_entries ()) r =KVM_MAX_VCPUS ;arch/x86/kvm/x86.c +3
-0@@ -3122,6 +3122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_PV_MMU :/* obsolete */ r =0 ;break ;virt/kvm/arm/arm.c +3
-0@@ -224,6 +224,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_MSI_DEVID :if (!kvm) r = -EINVAL ;virt/kvm/kvm_main.c +0
-2@@ -3146,8 +3146,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)case KVM_CAP_MULTI_ADDRESS_SPACE :return KVM_ADDRESS_SPACE_NUM ;#endif -case KVM_CAP_MAX_VCPU_ID : -return KVM_MAX_VCPU_ID ;case KVM_CAP_NR_MEMSLOTS :return KVM_USER_MEM_SLOTS ;default :Signature · 1 line
2.21.0
Re: [PATCH 8/9] KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
In reply to Thomas HuthOn Thu, 23 May 2019 18:43:08 +0200
Thomas Huth <thuth at redhat.com> wrote:
In the subject: s/unusabled/unusable/
Quoted 15 lines
KVM_CAP_MAX_VCPU_IDis currently always reportingKVM_MAX_VCPU_IDon all architectures. However, on s390x, the amount of usable CPUs is determined during runtime - it is depending on the features of the machine the code is running on. Since we are using thevcpu_idas an index into the SCA structures that are defined by the hardware (see e.g. thesca_add_vcpu()function), it is not only the amount of CPUs that is limited by the hard- ware, but also the range of IDs that we can use.
ThusKVM_CAP_MAX_VCPU_IDmust be determined during runtime on s390x, too. So the handling ofKVM_CAP_MAX_VCPU_IDhas to be moved from the common code into the architecture specific code, and on s390x we have to return the same value here as forKVM_CAP_MAX_VCPUS.
This problem has been discovered with thekvm_create_max_vcpusselftest. With this change applied, the selftest now passes on s390x, too.Signed-off-by Thomas Huth <thuth at redhat.com>
Quoted 8 lines
--- arch/mips/kvm/mips.c | 3 +++ arch/powerpc/kvm/powerpc.c | 3 +++ arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 +++ virt/kvm/arm/arm.c | 3 +++ virt/kvm/kvm_main.c | 2 -- 6 files changed, 13 insertions(+), 2 deletions(-)
Re: [PATCH 8/9] KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
In reply to Thomas HuthQuoted 98 lines · Thomas Huth
KVM_CAP_MAX_VCPU_IDis currently always reportingKVM_MAX_VCPU_IDon all architectures. However, on s390x, the amount of usable CPUs is determined during runtime - it is depending on the features of the machine the code is running on. Since we are using thevcpu_idas an index into the SCA structures that are defined by the hardware (see e.g. thesca_add_vcpu()function), it is not only the amount of CPUs that is limited by the hard- ware, but also the range of IDs that we can use.
ThusKVM_CAP_MAX_VCPU_IDmust be determined during runtime on s390x, too. So the handling ofKVM_CAP_MAX_VCPU_IDhas to be moved from the common code into the architecture specific code, and on s390x we have to return the same value here as forKVM_CAP_MAX_VCPUS.
This problem has been discovered with thekvm_create_max_vcpusselftest. With this change applied, the selftest now passes on s390x, too.Signed-off-by Thomas Huth <thuth at redhat.com>--- arch/mips/kvm/mips.c | 3 +++ arch/powerpc/kvm/powerpc.c | 3 +++ arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 +++ virt/kvm/arm/arm.c | 3 +++ virt/kvm/kvm_main.c | 2 -- 6 files changed, 13 insertions(+), 2 deletions(-)arch/mips/kvm/mips.c +3
-0@@ -1122,6 +1122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_MIPS_FPU :/* We don't handle systems with inconsistent cpu_has_fpu */ r = !!raw_cpu_has_fpu;arch/powerpc/kvm/powerpc.c +3
-0@@ -657,6 +657,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;#ifdef CONFIG_PPC_BOOK3S_64 case KVM_CAP_PPC_GET_SMMU_INFO : r =1 ;arch/s390/kvm/kvm-s390.c +1
-0@@ -539,6 +539,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)break ;case KVM_CAP_NR_VCPUS :case KVM_CAP_MAX_VCPUS : +case KVM_CAP_MAX_VCPU_ID : r =KVM_S390_BSCA_CPU_SLOTS ;if (!kvm_s390_use_sca_entries ()) r =KVM_MAX_VCPUS ;arch/x86/kvm/x86.c +3
-0@@ -3122,6 +3122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_PV_MMU :/* obsolete */ r =0 ;break ;virt/kvm/arm/arm.c +3
-0@@ -224,6 +224,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_MSI_DEVID :if (!kvm) r = -EINVAL ;virt/kvm/kvm_main.c +0
-0
virt/kvm/kvm_main.c static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) · line 3151
Quoted 8 lines
virt/kvm/kvm_main.c +0
-2@@ -3146,8 +3146,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)case KVM_CAP_MULTI_ADDRESS_SPACE :return KVM_ADDRESS_SPACE_NUM ;#endif -case KVM_CAP_MAX_VCPU_ID : -return KVM_MAX_VCPU_ID ;case KVM_CAP_NR_MEMSLOTS :return KVM_USER_MEM_SLOTS ;default :
Signature · 3 lines
Thanks, David / dhildenb
Re: [PATCH 8/9] KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
In reply to Thomas HuthPaolo, Radim,
would you consider this patch (or the full series) as 5.2 material or 5.3 material?
Quoted 106 lines · Thomas Huth
KVM_CAP_MAX_VCPU_IDis currently always reportingKVM_MAX_VCPU_IDon all architectures. However, on s390x, the amount of usable CPUs is determined during runtime - it is depending on the features of the machine the code is running on. Since we are using thevcpu_idas an index into the SCA structures that are defined by the hardware (see e.g. thesca_add_vcpu()function), it is not only the amount of CPUs that is limited by the hard- ware, but also the range of IDs that we can use.
ThusKVM_CAP_MAX_VCPU_IDmust be determined during runtime on s390x, too. So the handling ofKVM_CAP_MAX_VCPU_IDhas to be moved from the common code into the architecture specific code, and on s390x we have to return the same value here as forKVM_CAP_MAX_VCPUS.
This problem has been discovered with thekvm_create_max_vcpusselftest. With this change applied, the selftest now passes on s390x, too.Signed-off-by Thomas Huth <thuth at redhat.com>--- arch/mips/kvm/mips.c | 3 +++ arch/powerpc/kvm/powerpc.c | 3 +++ arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 +++ virt/kvm/arm/arm.c | 3 +++ virt/kvm/kvm_main.c | 2 -- 6 files changed, 13 insertions(+), 2 deletions(-)arch/mips/kvm/mips.c +3
-0@@ -1122,6 +1122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_MIPS_FPU :/* We don't handle systems with inconsistent cpu_has_fpu */ r = !!raw_cpu_has_fpu;arch/powerpc/kvm/powerpc.c +3
-0@@ -657,6 +657,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;#ifdef CONFIG_PPC_BOOK3S_64 case KVM_CAP_PPC_GET_SMMU_INFO : r =1 ;arch/s390/kvm/kvm-s390.c +1
-0@@ -539,6 +539,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)break ;case KVM_CAP_NR_VCPUS :case KVM_CAP_MAX_VCPUS : +case KVM_CAP_MAX_VCPU_ID : r =KVM_S390_BSCA_CPU_SLOTS ;if (!kvm_s390_use_sca_entries ()) r =KVM_MAX_VCPUS ;arch/x86/kvm/x86.c +3
-0@@ -3122,6 +3122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_PV_MMU :/* obsolete */ r =0 ;break ;virt/kvm/arm/arm.c +3
-0@@ -224,6 +224,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_MAX_VCPUS : r =KVM_MAX_VCPUS ;break ; +case KVM_CAP_MAX_VCPU_ID : + r =KVM_MAX_VCPU_ID ; +break ;case KVM_CAP_MSI_DEVID :if (!kvm) r = -EINVAL ;virt/kvm/kvm_main.c +0
-2@@ -3146,8 +3146,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)case KVM_CAP_MULTI_ADDRESS_SPACE :return KVM_ADDRESS_SPACE_NUM ;#endif -case KVM_CAP_MAX_VCPU_ID : -return KVM_MAX_VCPU_ID ;case KVM_CAP_NR_MEMSLOTS :return KVM_USER_MEM_SLOTS ;default :
Re: [PATCH 8/9] KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
Quoted 3 lines · On Tue, 28 May 2019 13:00:30 +0200 Christian Borntraeger…
Paolo, Radim,
would you consider this patch (or the full series) as 5.2 material or 5.3 material?
FWIW, I'd consider this patch 5.2 material, as we're currently relaying wrong values to userspace.
Quoted 26 lines · Thomas Huth
Quoted 23 lines
KVM_CAP_MAX_VCPU_IDis currently always reportingKVM_MAX_VCPU_IDon all architectures. However, on s390x, the amount of usable CPUs is determined during runtime - it is depending on the features of the machine the code is running on. Since we are using thevcpu_idas an index into the SCA structures that are defined by the hardware (see e.g. thesca_add_vcpu()function), it is not only the amount of CPUs that is limited by the hard- ware, but also the range of IDs that we can use.
ThusKVM_CAP_MAX_VCPU_IDmust be determined during runtime on s390x, too. So the handling ofKVM_CAP_MAX_VCPU_IDhas to be moved from the common code into the architecture specific code, and on s390x we have to return the same value here as forKVM_CAP_MAX_VCPUS.
This problem has been discovered with thekvm_create_max_vcpusselftest. With this change applied, the selftest now passes on s390x, too.Signed-off-by Thomas Huth <thuth at redhat.com>--- arch/mips/kvm/mips.c | 3 +++ arch/powerpc/kvm/powerpc.c | 3 +++ arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 +++ virt/kvm/arm/arm.c | 3 +++ virt/kvm/kvm_main.c | 2 -- 6 files changed, 13 insertions(+), 2 deletions(-)
Re: Re: [PATCH 8/9] KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
Quoted 9 lines · Cornelia Huck
Quoted 3 lines · On Tue, 28 May 2019 13:00:30 +0200 Christian Borntraeger <borntraeger at…
Paolo, Radim,
would you consider this patch (or the full series) as 5.2 material or 5.3 material?
FWIW, I'd consider this patch 5.2 material, as we're currently relaying wrong values to userspace.
Agreed. I will add cc stable and queue for master. What is our opinion about kselftest? Are we merging testtools changes also only during the merge window?
Quoted 28 lines
Quoted 27 lines · Thomas Huth
Quoted 23 lines
KVM_CAP_MAX_VCPU_IDis currently always reportingKVM_MAX_VCPU_IDon all architectures. However, on s390x, the amount of usable CPUs is determined during runtime - it is depending on the features of the machine the code is running on. Since we are using thevcpu_idas an index into the SCA structures that are defined by the hardware (see e.g. thesca_add_vcpu()function), it is not only the amount of CPUs that is limited by the hard- ware, but also the range of IDs that we can use.
ThusKVM_CAP_MAX_VCPU_IDmust be determined during runtime on s390x, too. So the handling ofKVM_CAP_MAX_VCPU_IDhas to be moved from the common code into the architecture specific code, and on s390x we have to return the same value here as forKVM_CAP_MAX_VCPUS.
This problem has been discovered with thekvm_create_max_vcpusselftest. With this change applied, the selftest now passes on s390x, too.Signed-off-by Thomas Huth <thuth at redhat.com>--- arch/mips/kvm/mips.c | 3 +++ arch/powerpc/kvm/powerpc.c | 3 +++ arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 +++ virt/kvm/arm/arm.c | 3 +++ virt/kvm/kvm_main.c | 2 -- 6 files changed, 13 insertions(+), 2 deletions(-)
PATCH 9/9 KVM: selftests: Move kvm_create_max_vcpus test to generic code
In reply to Thomas HuthThere is nothing x86-specific in the test apart from the VM_MODE_P52V48_4K which we can now replace with VM_MODE_DEFAULT. Thus let's move the file to the main folder and enable it for aarch64 and s390x, too.
---
tools/testing/selftests/kvm/Makefile | 4 +++-
.../testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
rename tools/testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c (93%)tools/testing/selftests/kvm/Makefile +3 -1
@@ -21,15 +21,17 @@ TEST_GEN_PROGS_x86_64 += x86_64/evmcs_test TEST_GEN_PROGS_x86_64 += x86_64/hyperv_cpuid TEST_GEN_PROGS_x86_64 += x86_64/vmx_close_while_nested_test TEST_GEN_PROGS_x86_64 += x86_64/smm_test -TEST_GEN_PROGS_x86_64 += x86_64/kvm_create_max_vcpus TEST_GEN_PROGS_x86_64 += x86_64/vmx_set_nested_state_test +TEST_GEN_PROGS_x86_64 += kvm_create_max_vcpus TEST_GEN_PROGS_x86_64 += dirty_log_test TEST_GEN_PROGS_x86_64 += clear_dirty_log_test TEST_GEN_PROGS_aarch64 += dirty_log_test TEST_GEN_PROGS_aarch64 += clear_dirty_log_test +TEST_GEN_PROGS_aarch64 += kvm_create_max_vcpus TEST_GEN_PROGS_s390x += s390x/sync_regs_test +TEST_GEN_PROGS_s390x += kvm_create_max_vcpus TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(UNAME_M)) LIBKVM += $(LIBKVM_$(UNAME_M))
tools/testing/selftests/kvm/kvm_create_max_vcpus.c renamed from tools/testing/selftests/kvm/x86_64/kvm_create_max_vcpus.c +2 -1
@@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-only /* * kvm_create_max_vcpus *
@@ -28,7 +29,7 @@ void test_vcpu_creation(int first_vcpu_id, int num_vcpus)printf ("Testing creating %d vCPUs, with IDs %d...%d.\n" , num_vcpus, first_vcpu_id, first_vcpu_id + num_vcpus -1 ); - vm =vm_create (VM_MODE_P52V48_4K ,DEFAULT_GUEST_PHY_PAGES ,O_RDWR ); + vm =vm_create (VM_MODE_DEFAULT ,DEFAULT_GUEST_PHY_PAGES ,O_RDWR );for (i =0 ; i < num_vcpus; i++) {int vcpu_id = first_vcpu_id + i;
Signature · 1 line
2.21.0
Re: [PATCH 9/9] KVM: selftests: Move kvm_create_max_vcpus test to generic code
Quoted 58 lines · Thomas Huth
There is nothing x86-specific in the test apart from the
VM_MODE_P52V48_4Kwhich we can now replace withVM_MODE_DEFAULT. Thus let's move the file to the main folder and enable it for aarch64 and s390x, too.Signed-off-by Thomas Huth <thuth at redhat.com>--- tools/testing/selftests/kvm/Makefile | 4 +++- .../testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c | 3 ++- 2 files changed, 5 insertions(+), 2 deletions(-) rename tools/testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c (93%)tools/testing/selftests/kvm/Makefile +3
-1@@ -21,15 +21,17 @@ TEST_GEN_PROGS_x86_64 += x86_64/evmcs_test TEST_GEN_PROGS_x86_64 += x86_64/hyperv_cpuid TEST_GEN_PROGS_x86_64 += x86_64/vmx_close_while_nested_test TEST_GEN_PROGS_x86_64 += x86_64/smm_test -TEST_GEN_PROGS_x86_64 += x86_64/kvm_create_max_vcpus TEST_GEN_PROGS_x86_64 += x86_64/vmx_set_nested_state_test +TEST_GEN_PROGS_x86_64 += kvm_create_max_vcpus TEST_GEN_PROGS_x86_64 += dirty_log_test TEST_GEN_PROGS_x86_64 += clear_dirty_log_test TEST_GEN_PROGS_aarch64 += dirty_log_test TEST_GEN_PROGS_aarch64 += clear_dirty_log_test +TEST_GEN_PROGS_aarch64 += kvm_create_max_vcpus TEST_GEN_PROGS_s390x += s390x/sync_regs_test +TEST_GEN_PROGS_s390x += kvm_create_max_vcpus TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(UNAME_M)) LIBKVM += $(LIBKVM_$(UNAME_M))tools/testing/selftests/kvm/kvm_create_max_vcpus.c renamed from tools/testing/selftests/kvm/x86_64/kvm_create_max_vcpus.c +2
-1@@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-only /* * kvm_create_max_vcpus * @@ -28,7 +29,7 @@ void test_vcpu_creation(int first_vcpu_id, int num_vcpus)printf ("Testing creating %d vCPUs, with IDs %d...%d.\n" , num_vcpus, first_vcpu_id, first_vcpu_id + num_vcpus -1 ); - vm =vm_create (VM_MODE_P52V48_4K ,DEFAULT_GUEST_PHY_PAGES ,O_RDWR ); + vm =vm_create (VM_MODE_DEFAULT ,DEFAULT_GUEST_PHY_PAGES ,O_RDWR );for (i =0 ; i < num_vcpus; i++) {int vcpu_id = first_vcpu_id + i;Signature · 1 line
2.21.0
Re: [PATCH 9/9] KVM: selftests: Move kvm_create_max_vcpus test to generic code
In reply to Thomas HuthQuoted 48 lines · Thomas Huth
There is nothing x86-specific in the test apart from the
VM_MODE_P52V48_4Kwhich we can now replace withVM_MODE_DEFAULT. Thus let's move the file to the main folder and enable it for aarch64 and s390x, too.Signed-off-by Thomas Huth <thuth at redhat.com>--- tools/testing/selftests/kvm/Makefile | 4 +++- .../testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c | 3 ++- 2 files changed, 5 insertions(+), 2 deletions(-) rename tools/testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c (93%)tools/testing/selftests/kvm/Makefile +3
-1@@ -21,15 +21,17 @@ TEST_GEN_PROGS_x86_64 += x86_64/evmcs_test TEST_GEN_PROGS_x86_64 += x86_64/hyperv_cpuid TEST_GEN_PROGS_x86_64 += x86_64/vmx_close_while_nested_test TEST_GEN_PROGS_x86_64 += x86_64/smm_test -TEST_GEN_PROGS_x86_64 += x86_64/kvm_create_max_vcpus TEST_GEN_PROGS_x86_64 += x86_64/vmx_set_nested_state_test +TEST_GEN_PROGS_x86_64 += kvm_create_max_vcpus TEST_GEN_PROGS_x86_64 += dirty_log_test TEST_GEN_PROGS_x86_64 += clear_dirty_log_test TEST_GEN_PROGS_aarch64 += dirty_log_test TEST_GEN_PROGS_aarch64 += clear_dirty_log_test +TEST_GEN_PROGS_aarch64 += kvm_create_max_vcpus TEST_GEN_PROGS_s390x += s390x/sync_regs_test +TEST_GEN_PROGS_s390x += kvm_create_max_vcpus TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(UNAME_M)) LIBKVM += $(LIBKVM_$(UNAME_M))tools/testing/selftests/kvm/kvm_create_max_vcpus.c renamed from tools/testing/selftests/kvm/x86_64/kvm_create_max_vcpus.c +1
-0@@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-only /* * kvm_create_max_vcpus *
tools/testing/selftests/kvm/kvm_create_max_vcpus.c void test_vcpu_creation(int first_vcpu_id, int num_vcpus) · line 35
Quoted 8 lines
tools/testing/selftests/kvm/kvm_create_max_vcpus.c renamed from tools/testing/selftests/kvm/x86_64/kvm_create_max_vcpus.c +1
-1@@ -28,7 +29,7 @@ void test_vcpu_creation(int first_vcpu_id, int num_vcpus)printf ("Testing creating %d vCPUs, with IDs %d...%d.\n" , num_vcpus, first_vcpu_id, first_vcpu_id + num_vcpus -1 ); - vm =vm_create (VM_MODE_P52V48_4K ,DEFAULT_GUEST_PHY_PAGES ,O_RDWR ); + vm =vm_create (VM_MODE_DEFAULT ,DEFAULT_GUEST_PHY_PAGES ,O_RDWR );for (i =0 ; i < num_vcpus; i++) {int vcpu_id = first_vcpu_id + i;
Signature · 3 lines
Thanks, David / dhildenb
PATCH 1/1 KVM: selftests: enable pgste option for the linker on s390
In reply to Thomas HuthTo avoid testcase failures we need to enable the pgstes. This can be done with /proc/sys/vm/allocate_pgste or with a linker option that creates an S390_PGSTE program header.
--- tools/testing/selftests/kvm/Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
tools/testing/selftests/kvm/Makefile +4 -1
@@ -44,7 +44,10 @@ CFLAGS += -O2 -g -std=gnu99 -fno-stack-protector -fno-PIE -I$(LINUX_TOOL_INCLUDE no-pie-option := $(call try-run, echo 'int main() { return 0; }' | \ $(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -no-pie -x c - -o "$$TMP", -no-pie) -LDFLAGS += -pthread $(no-pie-option) +# On s390, build the testcases KVM-enabled +pgste-option := $(call cc-ldoption, -Wl$(comma)--s390-pgste) + +LDFLAGS += -pthread $(no-pie-option) $(pgste-option) # After inclusion, $(OUTPUT) is defined and # $(TEST_GEN_PROGS) starts with $(OUTPUT)/
Signature · 1 line
2.21.0
Re: [PATCH] KVM: selftests: enable pgste option for the linker on s390
Quoted 3 lines · Christian Borntraeger
To avoid testcase failures we need to enable the pgstes. This can be done with
/proc/sys/vm/allocate_pgsteor with a linker option that creates anS390_PGSTEprogram header.
Oh, right, I initially enabled it on my LPAR via "sysctl vm.allocate_pgste=1" when I started working on the selftests and then completely forgot about this... The linker option is certainly the better way to do this, thanks for the patch!
Re: [PATCH] KVM: selftests: enable pgste option for the linker on s390
In reply to Christian BorntraegerQuoted 16 lines · Christian Borntraeger
To avoid testcase failures we need to enable the pgstes. This can be done with
/proc/sys/vm/allocate_pgsteor with a linker option that creates anS390_PGSTEprogram header.Signed-off-by Christian Borntraeger <borntraeger at de.ibm.com>--- tools/testing/selftests/kvm/Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)tools/testing/selftests/kvm/Makefile +0
-0@@ -44,7 +44,10 @@ CFLAGS += -O2 -g -std=gnu99 -fno-stack-protector -fno-PIE -I$(LINUX_TOOL_INCLUDE no-pie-option := $(call try-run, echo 'int main() { return 0; }' | \
tools/testing/selftests/kvm/Makefile CFLAGS += -O2 -g -std=gnu99 -fno-stack-protector -fno-PIE -I$(LINUX_TOOL_INCLUDE · line 53
Quoted 10 lines
tools/testing/selftests/kvm/Makefile +4
-1$(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -no-pie -x c - -o "$$TMP", -no-pie) -LDFLAGS += -pthread $(no-pie-option) +# On s390, build the testcases KVM-enabled +pgste-option := $(call cc-ldoption, -Wl$(comma)--s390-pgste) + +LDFLAGS += -pthread $(no-pie-option) $(pgste-option) # After inclusion, $(OUTPUT) is defined and # $(TEST_GEN_PROGS) starts with $(OUTPUT)/
Signature · 3 lines
Thanks, David / dhildenb
Re: [PATCH] KVM: selftests: enable pgste option for the linker on s390
In reply to Christian BorntraegerQuoted 16 lines · Christian Borntraeger
To avoid testcase failures we need to enable the pgstes. This can be done with
/proc/sys/vm/allocate_pgsteor with a linker option that creates anS390_PGSTEprogram header.Signed-off-by Christian Borntraeger <borntraeger at de.ibm.com>--- tools/testing/selftests/kvm/Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)tools/testing/selftests/kvm/Makefile +0
-0@@ -44,7 +44,10 @@ CFLAGS += -O2 -g -std=gnu99 -fno-stack-protector -fno-PIE -I$(LINUX_TOOL_INCLUDE no-pie-option := $(call try-run, echo 'int main() { return 0; }' | \
tools/testing/selftests/kvm/Makefile CFLAGS += -O2 -g -std=gnu99 -fno-stack-protector -fno-PIE -I$(LINUX_TOOL_INCLUDE · line 53
Quoted 10 lines
tools/testing/selftests/kvm/Makefile +4
-1$(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -no-pie -x c - -o "$$TMP", -no-pie) -LDFLAGS += -pthread $(no-pie-option) +# On s390, build the testcases KVM-enabled +pgste-option := $(call cc-ldoption, -Wl$(comma)--s390-pgste) + +LDFLAGS += -pthread $(no-pie-option) $(pgste-option) # After inclusion, $(OUTPUT) is defined and # $(TEST_GEN_PROGS) starts with $(OUTPUT)/
After commit commit 055efab3120bae7ab1ed841317774f3c953f6e1b (kbuild: drop support for cc-ldoption) I had to change that in the following way.
tools/testing/selftests/kvm/Makefile +1 -1
@@ -48,7 +48,7 @@ no-pie-option := $(call try-run, echo 'int main() { return 0; }' | \ $(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -no-pie -x c - -o "$$TMP", -no-pie) # On s390, build the testcases KVM-enabled -pgste-option := $(call cc-ldoption, -Wl$(comma)--s390-pgste) +pgste-option := $(call cc-option,-Wl$(comma)--s390-pgste) LDFLAGS += -pthread $(no-pie-option) $(pgste-option)
With that pushed out to kvms390/next.
I do get
[10400.440298] kvm-s390: failed to commit memory region [10400.508723] kvm-s390: failed to commit memory region
when running the tests. Will have a look.
Quoted 56 lines · Thomas Huth
This patch series enables the KVM selftests for s390x. As a first test, the
sync_regsfrom x86 has been adapted to s390x, and after a fix forKVM_CAP_MAX_VCPU_IDon s390x, thekvm_create_max_vcpusis now enabled here, too.Please note that the
ucall()interface is not used yet - since s390x neither has PIO nor MMIO, this needs some more work first before it becomes usable (we likely should use a DIAG hypercall here, which is what thesync_regtest is currently using, too... I started working on that topic, but did not finish that work yet, so I decided to not include it yet).RFC -> v1:
- Rebase, needed to add the first patch for vcpu_nested_state_get/set
- Added patch to introduceVM_MODE_DEFAULTmacro
- Improved/cleaned up the code inprocessor.c
- Added patch to fixKVM_CAP_MAX_VCPU_IDon s390x
- Added patch to enable thekvm_create_max_vcpuson s390x and aarch64Andrew Jones (1):
kvm: selftests: aarch64: fix default vm modeThomas Huth (8):
KVM: selftests: Wrap vcpu_nested_state_get/set functions with x86
guard
KVM: selftests: Guard structkvm_vcpu_eventswith
__KVM_HAVE_VCPU_EVENTS
KVM: selftests: Introduce aVM_MODE_DEFAULTmacro for the default bits
KVM: selftests: Align memory region addresses to 1M on s390x
KVM: selftests: Add processor code for s390x
KVM: selftests: Add thesync_regstest for s390x
KVM: s390: Do not report unusabled IDs viaKVM_CAP_MAX_VCPU_ID
KVM: selftests: Movekvm_create_max_vcpustest to generic codeMAINTAINERS | 2 + arch/mips/kvm/mips.c | 3 + arch/powerpc/kvm/powerpc.c | 3 + arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 + tools/testing/selftests/kvm/Makefile | 7 +- .../testing/selftests/kvm/include/kvm_util.h | 10 + .../selftests/kvm/include/s390x/processor.h | 22 ++ .../kvm/{x86_64 => }/kvm_create_max_vcpus.c | 3 +- .../selftests/kvm/lib/aarch64/processor.c | 2 +- tools/testing/selftests/kvm/lib/kvm_util.c | 25 +- .../selftests/kvm/lib/s390x/processor.c | 286 ++++++++++++++++++ .../selftests/kvm/lib/x86_64/processor.c | 2 +- .../selftests/kvm/s390x/sync_regs_test.c | 151 +++++++++ virt/kvm/arm/arm.c | 3 + virt/kvm/kvm_main.c | 2 - 16 files changed, 514 insertions(+), 11 deletions(-) create mode 100644 tools/testing/selftests/kvm/include/s390x/processor.h rename tools/testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c (93%) create mode 100644 tools/testing/selftests/kvm/lib/s390x/processor.c create mode 100644 tools/testing/selftests/kvm/s390x/sync_regs_test.c
Quoted 6 lines · Christian Borntraeger
I do get
[10400.440298] kvm-s390: failed to commit memory region [10400.508723] kvm-s390: failed to commit memory regionwhen running the tests. Will have a look.
It comes from kvm_vm_free. This calls KVM_SET_USER_MEMORY_REGION with size 0, which the s390 code does not like.
Quoted 5 lines · Christian Borntraeger
Quoted 2 lines · Christian Borntraeger
I do get
Quoted 8 lines
Quoted 4 lines
[10400.440298] kvm-s390: failed to commit memory region [10400.508723] kvm-s390: failed to commit memory regionwhen running the tests. Will have a look.
It comes from
kvm_vm_free. This callsKVM_SET_USER_MEMORY_REGIONwith size 0, which the s390 code does not like.
The doc says about KVM_SET_USER_MEMORY_REGION:
This ioctl allows the user to create or modify a guest physical memory slot. When changing an existing slot, it may be moved in the guest physical memory space, or its flags may be modified. --> It may not be resized. <----
$ strace -f -e trace=ioctl tools/testing/selftests/kvm/s390x/sync_regs_test
ioctl(3, KVM_CHECK_EXTENSION, KVM_CAP_SYNC_REGS) = 1
ioctl(4, KVM_CHECK_EXTENSION, KVM_CAP_IMMEDIATE_EXIT) = 1
ioctl(3, KVM_CREATE_VM, 0) = 4
ioctl(4, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=0, guest_phys_addr=0, memory_size=2097152, userspace_addr=0x3ffac500000}) = 0
ioctl(4, KVM_CREATE_VCPU, 5) = 7
ioctl(8, KVM_GET_VCPU_MMAP_SIZE, 0) = 4096
ioctl(8, KVM_GET_VCPU_MMAP_SIZE, 0) = 4096
ioctl(7, KVM_GET_SREGS, 0x3ffef0fdb90) = 0
ioctl(7, KVM_SET_SREGS, 0x3ffef0fdb90) = 0
ioctl(7, KVM_GET_REGS, 0x3ffef0fdcf8) = 0
ioctl(7, KVM_SET_REGS, 0x3ffef0fdcf8) = 0
ioctl(7, KVM_GET_SREGS, 0x3ffef0fdd78) = 0
ioctl(7, KVM_SET_SREGS, 0x3ffef0fdd78) = 0
ioctl(7, KVM_RUN, 0) = 0
ioctl(7, KVM_GET_REGS, 0x3ffef0fdf90) = 0
ioctl(7, KVM_GET_SREGS, 0x3ffef0fe010) = 0
ioctl(7, KVM_RUN, 0) = 0
ioctl(7, KVM_GET_REGS, 0x3ffef0fdf90) = 0
ioctl(7, KVM_GET_SREGS, 0x3ffef0fe010) = 0
ioctl(7, KVM_RUN, 0) = 0
ioctl(4, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=0, guest_phys_addr=0, memory_size=0, userspace_addr=0x3ffac500000}) = 0
+++ exited with 0 +++So the testcase is wrong? (I think the s390 code is also not fully correct will double check)
Quoted 17 lines · Christian Borntraeger
Quoted 5 lines · Christian Borntraeger
Quoted 2 lines · Christian Borntraeger
I do get
Quoted 8 lines
Quoted 4 lines
[10400.440298] kvm-s390: failed to commit memory region [10400.508723] kvm-s390: failed to commit memory regionwhen running the tests. Will have a look.
It comes from
kvm_vm_free. This callsKVM_SET_USER_MEMORY_REGIONwith size 0, which the s390 code does not like.
Quoted 6 lines
The doc says about
KVM_SET_USER_MEMORY_REGION:This ioctl allows the user to create or modify a guest physical memory slot. When changing an existing slot, it may be moved in the guest physical memory space, or its flags may be modified. --> It may not be resized. <----
Size 0 is deleting, not resizing AFAIK.
Signature · 3 lines
Thanks, David / dhildenb
Quoted 18 lines · David Hildenbrand
Quoted 17 lines · Christian Borntraeger
Quoted 13 lines · Christian Borntraeger
Quoted 6 lines · Christian Borntraeger
I do get
[10400.440298] kvm-s390: failed to commit memory region [10400.508723] kvm-s390: failed to commit memory regionwhen running the tests. Will have a look.
It comes from
kvm_vm_free. This callsKVM_SET_USER_MEMORY_REGIONwith size 0, which the s390 code does not like.
Quoted 8 lines
Quoted 6 lines
The doc says about
KVM_SET_USER_MEMORY_REGION:This ioctl allows the user to create or modify a guest physical memory slot. When changing an existing slot, it may be moved in the guest physical memory space, or its flags may be modified. --> It may not be resized. <----
Size 0 is deleting, not resizing AFAIK.
Right this seems to translate to KVM_MR_DELETE, which the s390 code does not handle (we will simply deliver a page fault as we share the last page table level). I will have a look at implementing KVM_MR_DELETE and KVM_MR_MOVE. In fact, we should have a testcase for that as well.
I have now queued every patch in the kselftest branch on kvms390 at kernel.org. I will push out for next as soon as I have some ack/nacks on the "KVM: s390: fix memory slot handling for KVM_SET_USER_MEMORY_REGION" patch.
Quoted 56 lines · Thomas Huth
This patch series enables the KVM selftests for s390x. As a first test, the
sync_regsfrom x86 has been adapted to s390x, and after a fix forKVM_CAP_MAX_VCPU_IDon s390x, thekvm_create_max_vcpusis now enabled here, too.Please note that the
ucall()interface is not used yet - since s390x neither has PIO nor MMIO, this needs some more work first before it becomes usable (we likely should use a DIAG hypercall here, which is what thesync_regtest is currently using, too... I started working on that topic, but did not finish that work yet, so I decided to not include it yet).RFC -> v1:
- Rebase, needed to add the first patch for vcpu_nested_state_get/set
- Added patch to introduceVM_MODE_DEFAULTmacro
- Improved/cleaned up the code inprocessor.c
- Added patch to fixKVM_CAP_MAX_VCPU_IDon s390x
- Added patch to enable thekvm_create_max_vcpuson s390x and aarch64Andrew Jones (1):
kvm: selftests: aarch64: fix default vm modeThomas Huth (8):
KVM: selftests: Wrap vcpu_nested_state_get/set functions with x86
guard
KVM: selftests: Guard structkvm_vcpu_eventswith
__KVM_HAVE_VCPU_EVENTS
KVM: selftests: Introduce aVM_MODE_DEFAULTmacro for the default bits
KVM: selftests: Align memory region addresses to 1M on s390x
KVM: selftests: Add processor code for s390x
KVM: selftests: Add thesync_regstest for s390x
KVM: s390: Do not report unusabled IDs viaKVM_CAP_MAX_VCPU_ID
KVM: selftests: Movekvm_create_max_vcpustest to generic codeMAINTAINERS | 2 + arch/mips/kvm/mips.c | 3 + arch/powerpc/kvm/powerpc.c | 3 + arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 + tools/testing/selftests/kvm/Makefile | 7 +- .../testing/selftests/kvm/include/kvm_util.h | 10 + .../selftests/kvm/include/s390x/processor.h | 22 ++ .../kvm/{x86_64 => }/kvm_create_max_vcpus.c | 3 +- .../selftests/kvm/lib/aarch64/processor.c | 2 +- tools/testing/selftests/kvm/lib/kvm_util.c | 25 +- .../selftests/kvm/lib/s390x/processor.c | 286 ++++++++++++++++++ .../selftests/kvm/lib/x86_64/processor.c | 2 +- .../selftests/kvm/s390x/sync_regs_test.c | 151 +++++++++ virt/kvm/arm/arm.c | 3 + virt/kvm/kvm_main.c | 2 - 16 files changed, 514 insertions(+), 11 deletions(-) create mode 100644 tools/testing/selftests/kvm/include/s390x/processor.h rename tools/testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c (93%) create mode 100644 tools/testing/selftests/kvm/lib/s390x/processor.c create mode 100644 tools/testing/selftests/kvm/s390x/sync_regs_test.c
Paolo Bonzini
maintainerQuoted 11 lines · Thomas Huth
This patch series enables the KVM selftests for s390x. As a first test, the
sync_regsfrom x86 has been adapted to s390x, and after a fix forKVM_CAP_MAX_VCPU_IDon s390x, thekvm_create_max_vcpusis now enabled here, too.Please note that the
ucall()interface is not used yet - since s390x neither has PIO nor MMIO, this needs some more work first before it becomes usable (we likely should use a DIAG hypercall here, which is what thesync_regtest is currently using, too... I started working on that topic, but did not finish that work yet, so I decided to not include it yet).
Christian, please include this in your tree (rebasing on top of kvm/next as soon as I push it). Note that Thomas is away for about a month.
Paolo
Quoted 44 lines
RFC -> v1:
- Rebase, needed to add the first patch for vcpu_nested_state_get/set
- Added patch to introduceVM_MODE_DEFAULTmacro
- Improved/cleaned up the code inprocessor.c
- Added patch to fixKVM_CAP_MAX_VCPU_IDon s390x
- Added patch to enable thekvm_create_max_vcpuson s390x and aarch64Andrew Jones (1):
kvm: selftests: aarch64: fix default vm modeThomas Huth (8):
KVM: selftests: Wrap vcpu_nested_state_get/set functions with x86
guard
KVM: selftests: Guard structkvm_vcpu_eventswith
__KVM_HAVE_VCPU_EVENTS
KVM: selftests: Introduce aVM_MODE_DEFAULTmacro for the default bits
KVM: selftests: Align memory region addresses to 1M on s390x
KVM: selftests: Add processor code for s390x
KVM: selftests: Add thesync_regstest for s390x
KVM: s390: Do not report unusabled IDs viaKVM_CAP_MAX_VCPU_ID
KVM: selftests: Movekvm_create_max_vcpustest to generic codeMAINTAINERS | 2 + arch/mips/kvm/mips.c | 3 + arch/powerpc/kvm/powerpc.c | 3 + arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 + tools/testing/selftests/kvm/Makefile | 7 +- .../testing/selftests/kvm/include/kvm_util.h | 10 + .../selftests/kvm/include/s390x/processor.h | 22 ++ .../kvm/{x86_64 => }/kvm_create_max_vcpus.c | 3 +- .../selftests/kvm/lib/aarch64/processor.c | 2 +- tools/testing/selftests/kvm/lib/kvm_util.c | 25 +- .../selftests/kvm/lib/s390x/processor.c | 286 ++++++++++++++++++ .../selftests/kvm/lib/x86_64/processor.c | 2 +- .../selftests/kvm/s390x/sync_regs_test.c | 151 +++++++++ virt/kvm/arm/arm.c | 3 + virt/kvm/kvm_main.c | 2 - 16 files changed, 514 insertions(+), 11 deletions(-) create mode 100644 tools/testing/selftests/kvm/include/s390x/processor.h rename tools/testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c (93%) create mode 100644 tools/testing/selftests/kvm/lib/s390x/processor.c create mode 100644 tools/testing/selftests/kvm/s390x/sync_regs_test.c
Quoted 13 lines · Paolo Bonzini
Quoted 11 lines · Thomas Huth
This patch series enables the KVM selftests for s390x. As a first test, the
sync_regsfrom x86 has been adapted to s390x, and after a fix forKVM_CAP_MAX_VCPU_IDon s390x, thekvm_create_max_vcpusis now enabled here, too.Please note that the
ucall()interface is not used yet - since s390x neither has PIO nor MMIO, this needs some more work first before it becomes usable (we likely should use a DIAG hypercall here, which is what thesync_regtest is currently using, too... I started working on that topic, but did not finish that work yet, so I decided to not include it yet).
Quoted 2 lines
Christian, please include this in your tree (rebasing on top of kvm/next as soon as I push it). Note that Thomas is away for about a month.
Will do. Right now it is part of my next tree on top of rc3.
Quoted 48 lines
Paolo
Quoted 44 lines
RFC -> v1:
- Rebase, needed to add the first patch for vcpu_nested_state_get/set
- Added patch to introduceVM_MODE_DEFAULTmacro
- Improved/cleaned up the code inprocessor.c
- Added patch to fixKVM_CAP_MAX_VCPU_IDon s390x
- Added patch to enable thekvm_create_max_vcpuson s390x and aarch64Andrew Jones (1):
kvm: selftests: aarch64: fix default vm modeThomas Huth (8):
KVM: selftests: Wrap vcpu_nested_state_get/set functions with x86
guard
KVM: selftests: Guard structkvm_vcpu_eventswith
__KVM_HAVE_VCPU_EVENTS
KVM: selftests: Introduce aVM_MODE_DEFAULTmacro for the default bits
KVM: selftests: Align memory region addresses to 1M on s390x
KVM: selftests: Add processor code for s390x
KVM: selftests: Add thesync_regstest for s390x
KVM: s390: Do not report unusabled IDs viaKVM_CAP_MAX_VCPU_ID
KVM: selftests: Movekvm_create_max_vcpustest to generic codeMAINTAINERS | 2 + arch/mips/kvm/mips.c | 3 + arch/powerpc/kvm/powerpc.c | 3 + arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 + tools/testing/selftests/kvm/Makefile | 7 +- .../testing/selftests/kvm/include/kvm_util.h | 10 + .../selftests/kvm/include/s390x/processor.h | 22 ++ .../kvm/{x86_64 => }/kvm_create_max_vcpus.c | 3 +- .../selftests/kvm/lib/aarch64/processor.c | 2 +- tools/testing/selftests/kvm/lib/kvm_util.c | 25 +- .../selftests/kvm/lib/s390x/processor.c | 286 ++++++++++++++++++ .../selftests/kvm/lib/x86_64/processor.c | 2 +- .../selftests/kvm/s390x/sync_regs_test.c | 151 +++++++++ virt/kvm/arm/arm.c | 3 + virt/kvm/kvm_main.c | 2 - 16 files changed, 514 insertions(+), 11 deletions(-) create mode 100644 tools/testing/selftests/kvm/include/s390x/processor.h rename tools/testing/selftests/kvm/{x86_64 => }/kvm_create_max_vcpus.c (93%) create mode 100644 tools/testing/selftests/kvm/lib/s390x/processor.c create mode 100644 tools/testing/selftests/kvm/s390x/sync_regs_test.c