KVM selftests for s390x

RFC PATCH In review Thomas Huth 5 participants 19 messages May 16, 2019 – May 23, 2019

Subsystems (3)

KVM Kselftest s390

lore

Share & tools

lore

Thomas Huth

author

2019-05-16 11:12 UTC #0 lore raw

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.

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...).

Thomas Huth (4):
KVM: selftests: Guard struct kvm_vcpu_events with
__KVM_HAVE_VCPU_EVENTS
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

 MAINTAINERS                                   |   2 +
 tools/testing/selftests/kvm/Makefile          |   3 +
 .../testing/selftests/kvm/include/kvm_util.h  |   2 +
 .../selftests/kvm/include/s390x/processor.h   |  22 ++
 tools/testing/selftests/kvm/lib/kvm_util.c    |  24 +-
 .../selftests/kvm/lib/s390x/processor.c       | 277 ++++++++++++++++++
 .../selftests/kvm/s390x/sync_regs_test.c      | 151 ++++++++++
 7 files changed, 476 insertions(+), 5 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/include/s390x/processor.h
 create mode 100644 tools/testing/selftests/kvm/lib/s390x/processor.c
 create mode 100644 tools/testing/selftests/kvm/s390x/sync_regs_test.c

Signature · 1 line

2.21.0

Thomas Huth

author

2019-05-16 11:12 UTC #1 lore raw

RFC PATCH 1/4 KVM: selftests: Guard struct kvm_vcpu_events with __KVM_HAVE_VCPU_EVENTS

The 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've got to fence the code with __KVM_HAVE_VCPU_EVENTS.

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

index 07b71ad9734a..1e46ab205038 100644
@@ -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_EVENTS
 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);
+#endif
 
 const char *exit_reason_str(unsigned int exit_reason);

tools/testing/selftests/kvm/lib/kvm_util.c +2 -0

index 4ca96b228e46..8d63ccb93e10 100644
@@ -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_EVENTS
 void 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
 
 /*
  * VM VCPU System Regs Get

Signature · 1 line

2.21.0

David Hildenbrand

Reviewed-by on v1 1/4

2019-05-16 11:22 UTC #2 lore raw

Re: [RFC PATCH 1/4] KVM: selftests: Guard struct kvm_vcpu_events with __KVM_HAVE_VCPU_EVENTS

Quoted 41 lines · Thomas Huth

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

index 07b71ad9734a..1e46ab205038 100644
@@ -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_EVENTS
 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);
+#endif
 
 const char *exit_reason_str(unsigned int exit_reason);

tools/testing/selftests/kvm/lib/kvm_util.c +1 -0

index 4ca96b228e46..8d63ccb93e10 100644
@@ -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_EVENTS
 void vcpu_events_get(struct kvm_vm *vm, uint32_t vcpuid,
 		     struct kvm_vcpu_events *events)
 {

tools/testing/selftests/kvm/lib/kvm_util.c void vcpu_events_set(struct kvm_vm *vm, uint32_t vcpuid, · line 1256

Quoted 7 lines

tools/testing/selftests/kvm/lib/kvm_util.c +1 -0

@@ -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
 
 /*
  * VM VCPU System Regs Get

Reviewed-by David Hildenbrand <david at redhat.com>

Signature · 3 lines

Thanks,

David / dhildenb

Christian Borntraeger

Acked-by on v1 1/4

2019-05-20 07:12 UTC #3 lore raw

Re: [RFC PATCH 1/4] KVM: selftests: Guard struct kvm_vcpu_events with __KVM_HAVE_VCPU_EVENTS

In reply to Thomas Huth

Quoted 5 lines · Thomas Huth

The 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've got to fence the code with __KVM_HAVE_VCPU_EVENTS.
Signed-off-by Thomas Huth <thuth at redhat.com>

Acked-by Christian Borntraeger <borntraeger at de.ibm.com>

According to the MAINTAINERS patches, you want me to pick these patches. Correct?

Quoted 43 lines

---
 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

index 07b71ad9734a..1e46ab205038 100644
@@ -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_EVENTS
 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);
+#endif
 
 const char *exit_reason_str(unsigned int exit_reason);

tools/testing/selftests/kvm/lib/kvm_util.c +2 -0

index 4ca96b228e46..8d63ccb93e10 100644
@@ -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_EVENTS
 void 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
 
 /*
  * VM VCPU System Regs Get

Thomas Huth

author

2019-05-20 08:08 UTC #4 lore raw

Re: [RFC PATCH 1/4] KVM: selftests: Guard struct kvm_vcpu_events with __KVM_HAVE_VCPU_EVENTS

Quoted 10 lines · Christian Borntraeger

Quoted 5 lines · Thomas Huth
The 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've got to fence the code with __KVM_HAVE_VCPU_EVENTS.
Signed-off-by Thomas Huth <thuth at redhat.com>
Acked-by Christian Borntraeger <borntraeger at de.ibm.com>
According to the MAINTAINERS patches, you want me to pick these patches. Correct?

That would be nice, yes. But if you don't want to be responsible for s390x-related KVM selftest patches, please let me know, then I'll drop these hunks from the patches again.

Thomas

Christian Borntraeger

2019-05-20 08:13 UTC #5 lore raw

Re: [RFC PATCH 1/4] KVM: selftests: Guard struct kvm_vcpu_events with __KVM_HAVE_VCPU_EVENTS

Quoted 7 lines · Thomas Huth

Quoted 6 lines · Christian Borntraeger
Quoted 4 lines · Thomas Huth
The 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've got to fence the code with __KVM_HAVE_VCPU_EVENTS.

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
Signed-off-by Thomas Huth <thuth at redhat.com>
Acked-by Christian Borntraeger <borntraeger at de.ibm.com>
According to the MAINTAINERS patches, you want me to pick these patches. Correct?
That would be nice, yes. But if you don't want to be responsible for s390x-related KVM selftest patches, please let me know, then I'll drop these hunks from the patches again.

I can take care of these (as part of the normal KVM maintainership).

Thomas Huth

author

2019-05-16 11:12 UTC #6 lore raw

RFC PATCH 2/4 KVM: selftests: Align memory region addresses to 1M on s390x

In reply to 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 +16 -5

index 8d63ccb93e10..64a0da6efe3d 100644
@@ -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

David Hildenbrand

2019-05-16 11:30 UTC #7 lore raw

Re: [RFC PATCH 2/4] KVM: selftests: Align memory region addresses to 1M on s390x

Quoted 23 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
index 8d63ccb93e10..64a0da6efe3d 100644
@@ -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"

tools/testing/selftests/kvm/lib/kvm_util.c void vm_userspace_mem_region_add(struct kvm_vm *vm, · line 614

Quoted 7 lines

tools/testing/selftests/kvm/lib/kvm_util.c +3 -1

@@ -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;

This corresponds to huge_page_size, maybe you can exploit this fact here.

Something like

alignment = 1;

/* On s390x, the host address must always be aligned to the THP size */ #ifndef __s390x__
if (src_type == VM_MEM_SRC_ANONYMOUS_THP)

#endif
	alignment = huge_page_size;

Maybe in a nicer fashion. Not sure.

Quoted 28 lines

tools/testing/selftests/kvm/lib/kvm_util.c +12 -4

+#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 · 3 lines

Thanks,

David / dhildenb

Thomas Huth

author

2019-05-16 11:59 UTC #8 lore raw

Re: [RFC PATCH 2/4] KVM: selftests: Align memory region addresses to 1M on s390x

Quoted 38 lines · David Hildenbrand

Quoted 23 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
index 8d63ccb93e10..64a0da6efe3d 100644
@@ -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"
tools/testing/selftests/kvm/lib/kvm_util.c void vm_userspace_mem_region_add(struct kvm_vm *vm, · line 614
Quoted 7 lines
tools/testing/selftests/kvm/lib/kvm_util.c +3 -1
@@ -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;
This corresponds to huge_page_size, maybe you can exploit this fact here.
Something like
alignment = 1;

Quoted 7 lines

/* On s390x, the host address must always be aligned to the THP size */ #ifndef __s390x__
if (src_type == VM_MEM_SRC_ANONYMOUS_THP)
#endif
	alignment = huge_page_size;
Maybe in a nicer fashion. Not sure.

Hmm, but if I've got your explanation on IRC right, it's rather a coincidence that the huge page size matches the alignment requirements for KVM memslots, isn't it? So I think the code would look rather confusing if I'd try to shorten it this way...?

Thomas

David Hildenbrand

2019-05-16 12:08 UTC #9 lore raw

Re: [RFC PATCH 2/4] KVM: selftests: Align memory region addresses to 1M on s390x

Quoted 45 lines · Thomas Huth

Quoted 44 lines · David Hildenbrand
Quoted 23 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
index 8d63ccb93e10..64a0da6efe3d 100644
@@ -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"
tools/testing/selftests/kvm/lib/kvm_util.c void vm_userspace_mem_region_add(struct kvm_vm *vm, · line 614
Quoted 7 lines
tools/testing/selftests/kvm/lib/kvm_util.c +3 -1
@@ -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;
This corresponds to huge_page_size, maybe you can exploit this fact here.
Something like
alignment = 1;
/* On s390x, the host address must always be aligned to the THP size */ #ifndef __s390x__
if (src_type == VM_MEM_SRC_ANONYMOUS_THP)
#endif
	alignment = huge_page_size;

Quoted 6 lines

Quoted 1 line
Maybe in a nicer fashion. Not sure.
Hmm, but if I've got your explanation on IRC right, it's rather a coincidence that the huge page size matches the alignment requirements for KVM memslots, isn't it? So I think the code would look rather confusing if I'd try to shorten it this way...?

Well, it's not really a coincidence. We have to share page tables between the gmap and the user space process. One huge page corresponds to the pages covered by a page table. So the page table "size" dictates the alignment of both things.

But this is just nit picking here, do it the way you prefer, just wanted to point it out :)

Quoted 3 lines

Thomas

Signature · 3 lines

Thanks,

David / dhildenb

Thomas Huth

author

2019-05-16 11:12 UTC #10 lore raw

RFC PATCH 3/4 KVM: selftests: Add processor code for s390x

In reply to Thomas Huth

Code that takes care of basic CPU setup, page table walking, etc.

Signed-off-by Thomas Huth <thuth at redhat.com>

---
 MAINTAINERS                                   |   1 +
 tools/testing/selftests/kvm/Makefile          |   1 +
 .../selftests/kvm/include/s390x/processor.h   |  22 ++
 .../selftests/kvm/lib/s390x/processor.c       | 277 ++++++++++++++++++
 4 files changed, 301 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

index ee6cf4d1010c..514d1f88ee26 100644
@@ -8645,6 +8645,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

index f8588cca2bef..690422c78fb2 100644
@@ -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

new file mode 100644
index 000000000000..e0e96a5f608c
@@ -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 +277 -0

277 lines not on this page · raw message

Signature · 1 line

2.21.0

Thomas Huth

author

2019-05-16 11:12 UTC #11 lore raw

RFC PATCH 4/4 KVM: selftests: Add the sync_regs test for s390x

In reply to Thomas Huth

The 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.

Signed-off-by Thomas Huth <thuth at redhat.com>

---
 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

index 514d1f88ee26..68f76ee9e821 100644
@@ -8645,6 +8645,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

index 690422c78fb2..128b3551dfd0 100644
@@ -27,6 +27,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

Paolo Bonzini

maintainer

2019-05-20 11:19 UTC #12 lore raw

Re: [RFC PATCH 4/4] KVM: selftests: Add the sync_regs test for s390x

tools/testing/selftests/kvm/s390x/sync_regs_test.c line 31

Quoted 8 lines · Thomas Huth

tools/testing/selftests/kvm/s390x/sync_regs_test.c new file +8 -0

+#define VCPU_ID 5
+
+static void guest_code(void)
+{
+	for (;;) {
+		asm volatile ("diag 0,0,0x501");
+		asm volatile ("ahi 11,1");
+	}

I'd like this to use something like

	register u32 stage = 0 asm("11");
	...
	stage++

instead (yes, it should be fixed in x86 too).

Paolo

Andrew Jones

2019-05-23 10:56 UTC #13 lore raw

Re: [RFC PATCH 4/4] KVM: selftests: Add the sync_regs test for s390x

In reply to Thomas Huth

Quoted 20 lines · Thomas Huth

The 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.
Signed-off-by Thomas Huth <thuth at redhat.com>
---
 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 +0 -0
index 514d1f88ee26..68f76ee9e821 100644

MAINTAINERS F: arch/s390/include/asm/gmap.h · line 8649

Quoted 5 lines

MAINTAINERS +1 -0

@@ -8645,6 +8645,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/

Do we need these lines added? We have tools/testing/selftests/kvm/ in the common KVM section already. If we do want to specify them specifically, then I guess we need x86 and arm MAINTAINERS updates as well.

Thanks,
drew

Thomas Huth

author

2019-05-23 11:19 UTC #14 lore raw

Re: [RFC PATCH 4/4] KVM: selftests: Add the sync_regs test for s390x

Quoted 16 lines · Andrew Jones

Quoted 15 lines · Thomas Huth
The 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.
Signed-off-by Thomas Huth <thuth at redhat.com>
---
 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

Quoted 14 lines

MAINTAINERS F: arch/s390/include/asm/gmap.h · line 8649
Quoted 10 lines
MAINTAINERS +1 -0
index 514d1f88ee26..68f76ee9e821 100644
@@ -8645,6 +8645,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/
Do we need these lines added? We have tools/testing/selftests/kvm/ in the common KVM section already. If we do want to specify them specifically, then I guess we need x86 and arm MAINTAINERS updates as well.

I think they are helpful in the sense that the s390x maintainers get CC:-ed on related patches as well, and if I've got Christian right, he's interested in getting informed here. For Arm related patches, I guess you should ask the Arm maintainers first. For x86, it does not really matter, since the maintainers are the same.

Thomas

Paolo Bonzini

maintainer

2019-05-20 11:20 UTC #15 lore raw

In reply to Thomas Huth

Quoted 7 lines · Thomas Huth

This patch series enables the KVM selftests for s390x. As a first test, the sync_regs from x86 has been adapted to s390x.
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...).

No objections at all, though it would be like to have ucall plumbed in from the beginning.

Paolo

Thomas Huth

author

2019-05-20 11:30 UTC #16 lore raw

Quoted 11 lines · Paolo Bonzini

Quoted 7 lines · Thomas Huth
This patch series enables the KVM selftests for s390x. As a first test, the sync_regs from x86 has been adapted to s390x.
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...).
No objections at all, though it would be like to have ucall plumbed in from the beginning.

I'm still looking at the ucall interface ... what I don't quite get yet is the question why the ucall_type there is selectable during runtime?

Are there plans to have test that could either use UCALL_PIO or UCALL_MMIO? If not, what about moving ucall_init() and ucall() to architecture specific code in tools/testing/selftests/kvm/lib/aarch64/ and tools/testing/selftests/kvm/lib/x86_64 instead, and to remove the ucall_type stuff again (so that x86 is hard-wired to PIO and aarch64 is hard-wired to MMIO)? ... then I could add a DIAG-based ucall on s390x more easily, I think.

Thomas

Paolo Bonzini

maintainer

2019-05-20 11:43 UTC #17 lore raw

Quoted 5 lines · Thomas Huth

Quoted 2 lines
No objections at all, though it would be like to have ucall plumbed in from the beginning.
I'm still looking at the ucall interface ... what I don't quite get yet is the question why the ucall_type there is selectable during runtime?

Quoted 7 lines

Are there plans to have test that could either use UCALL_PIO or UCALL_MMIO? If not, what about moving ucall_init() and ucall() to architecture specific code in tools/testing/selftests/kvm/lib/aarch64/ and tools/testing/selftests/kvm/lib/x86_64 instead, and to remove the ucall_type stuff again (so that x86 is hard-wired to PIO and aarch64 is hard-wired to MMIO)? ... then I could add a DIAG-based ucall on s390x more easily, I think.

Yes, that would work. I think Andrew wanted the flexibility to use MMIO on x86, but it's not really necessary to have it.

Paolo

Andrew Jones

2019-05-22 08:44 UTC #18 lore raw

Quoted 14 lines · Paolo Bonzini

Quoted 5 lines · Thomas Huth
Quoted 2 lines
No objections at all, though it would be like to have ucall plumbed in from the beginning.
I'm still looking at the ucall interface ... what I don't quite get yet is the question why the ucall_type there is selectable during runtime?
Quoted 7 lines
Are there plans to have test that could either use UCALL_PIO or UCALL_MMIO? If not, what about moving ucall_init() and ucall() to architecture specific code in tools/testing/selftests/kvm/lib/aarch64/ and tools/testing/selftests/kvm/lib/x86_64 instead, and to remove the ucall_type stuff again (so that x86 is hard-wired to PIO and aarch64 is hard-wired to MMIO)? ... then I could add a DIAG-based ucall on s390x more easily, I think.

Quoted 2 lines

Yes, that would work. I think Andrew wanted the flexibility to use MMIO on x86, but it's not really necessary to have it.

If the flexibility isn't necessary, then I agree that it'll be nicer to put the ucall_init() in arch setup code, avoiding the need to remember it in each unit test.

Thanks,
drew