- Linux-kselftest-mirror - lists.linaro.org

[PATCH v1] um: Increase stack frame size threshold for signal.c

by Andy Shevchenko

The signal.c can't use heap for bit data located on stack. However, by default a compiler warns us about overstepping stack frame size threshold: arch/um/os-Linux/signal.c: In function ‘sig_handler_common’: arch/um/os-Linux/signal.c:51:1: warning: the frame size of 2960 bytes is larger than 2048 bytes [-Wframe-larger-than=] 51 | } | ^ arch/um/os-Linux/signal.c: In function ‘timer_real_alarm_handler’: arch/um/os-Linux/signal.c:95:1: warning: the frame size of 2960 bytes is larger than 2048 bytes [-Wframe-larger-than=] 95 | } | ^ Due to above increase stack frame size threshold explicitly for signal.c to avoid unnecessary warning. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- arch/um/os-Linux/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile index 839915b8c31c..77ac50baa3f8 100644 --- a/arch/um/os-Linux/Makefile +++ b/arch/um/os-Linux/Makefile @@ -10,6 +10,8 @@ obj-y = execvp.o file.o helper.o irq.o main.o mem.o process.o \ registers.o sigio.o signal.o start_up.o time.o tty.o \ umid.o user_syms.o util.o drivers/ skas/ +CFLAGS_signal.o += -Wframe-larger-than=4096 + obj-$(CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA) += elf_aux.o USER_OBJS := $(user-objs-y) elf_aux.o execvp.o file.o helper.o irq.o \ -- 2.29.2

4 years, 4 months

2
1
0 0

[PATCH net] selftests: fix poll error in udpgro.sh

by Paolo Abeni

The test program udpgso_bench_rx always invokes the poll() syscall with a timeout of 10ms. If a larger timeout is specified via the command line, udpgso_bench_rx is supposed to do multiple poll() calls till the timeout is expired or an event is received. Currently the poll() loop errors out after the first invocation with no events, and may causes self-tests failure alike: failed GRO with custom segment size ./udpgso_bench_rx: poll: 0x0 expected 0x1 This change addresses the issue allowing the poll() loop to consume all the configured timeout. Fixes: ada641ff6ed3 ("selftests: fixes for UDP GRO") Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> --- tools/testing/selftests/net/udpgso_bench_rx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/testing/selftests/net/udpgso_bench_rx.c b/tools/testing/selftests/net/udpgso_bench_rx.c index db3d4a8b5a4c..76a24052f4b4 100644 --- a/tools/testing/selftests/net/udpgso_bench_rx.c +++ b/tools/testing/selftests/net/udpgso_bench_rx.c @@ -113,6 +113,9 @@ static void do_poll(int fd, int timeout_ms) interrupted = true; break; } + + /* no events and more time to wait, do poll again */ + continue; } if (pfd.revents != POLLIN) error(1, errno, "poll: 0x%x expected 0x%x\n", -- 2.26.2

4 years, 4 months

1
0
0 0

Fwd: [PROBLEM] kmemleak: 2 new suspected memory leaks

by Jeffrin Jose T

4 years, 4 months

1
0
0 0

[PATCH v4] self_tests/kvm: sync_regs test for diag318

by Collin Walling

The DIAGNOSE 0x0318 instruction, unique to s390x, is a privileged call that must be intercepted via SIE, handled in userspace, and the information set by the instruction is communicated back to KVM. To test the instruction interception, an ad-hoc handler is defined which simply has a VM execute the instruction and then userspace will extract the necessary info. The handler is defined such that the instruction invocation occurs only once. It is up to the caller to determine how the info returned by this handler should be used. The diag318 info is communicated from userspace to KVM via a sync_regs call. This is tested During a sync_regs test, where the diag318 info is requested via the handler, then the info is stored in the appropriate register in KVM via a sync registers call. If KVM does not support diag318, then the tests will print a message stating that diag318 was skipped, and the asserts will simply test against a value of 0. Signed-off-by: Collin Walling <walling(a)linux.ibm.com> --- tools/testing/selftests/kvm/Makefile | 2 +- .../kvm/include/s390x/diag318_test_handler.h | 13 +++ .../kvm/lib/s390x/diag318_test_handler.c | 82 +++++++++++++++++++ .../selftests/kvm/s390x/sync_regs_test.c | 16 +++- 4 files changed, 111 insertions(+), 2 deletions(-) create mode 100644 tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h create mode 100644 tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile index 3d14ef77755e..426c78449044 100644 --- a/tools/testing/selftests/kvm/Makefile +++ b/tools/testing/selftests/kvm/Makefile @@ -36,7 +36,7 @@ endif LIBKVM = lib/assert.c lib/elf.c lib/io.c lib/kvm_util.c lib/sparsebit.c lib/test_util.c LIBKVM_x86_64 = lib/x86_64/processor.c lib/x86_64/vmx.c lib/x86_64/svm.c lib/x86_64/ucall.c lib/x86_64/handlers.S LIBKVM_aarch64 = lib/aarch64/processor.c lib/aarch64/ucall.c -LIBKVM_s390x = lib/s390x/processor.c lib/s390x/ucall.c +LIBKVM_s390x = lib/s390x/processor.c lib/s390x/ucall.c lib/s390x/diag318_test_handler.c TEST_GEN_PROGS_x86_64 = x86_64/cr4_cpuid_sync_test TEST_GEN_PROGS_x86_64 += x86_64/evmcs_test diff --git a/tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h b/tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h new file mode 100644 index 000000000000..b0ed71302722 --- /dev/null +++ b/tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h @@ -0,0 +1,13 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later + * + * Test handler for the s390x DIAGNOSE 0x0318 instruction. + * + * Copyright (C) 2020, IBM + */ + +#ifndef SELFTEST_KVM_DIAG318_TEST_HANDLER +#define SELFTEST_KVM_DIAG318_TEST_HANDLER + +uint64_t get_diag318_info(void); + +#endif diff --git a/tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c b/tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c new file mode 100644 index 000000000000..86b9e611ad87 --- /dev/null +++ b/tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c @@ -0,0 +1,82 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Test handler for the s390x DIAGNOSE 0x0318 instruction. + * + * Copyright (C) 2020, IBM + */ + +#include "test_util.h" +#include "kvm_util.h" + +#define VCPU_ID 6 + +#define ICPT_INSTRUCTION 0x04 +#define IPA0_DIAG 0x8300 + +static void guest_code(void) +{ + uint64_t diag318_info = 0x12345678; + + asm volatile ("diag %0,0,0x318\n" : : "d" (diag318_info)); +} + +/* + * The DIAGNOSE 0x0318 instruction call must be handled via userspace. As such, + * we create an ad-hoc VM here to handle the instruction then extract the + * necessary data. It is up to the caller to decide what to do with that data. + */ +static uint64_t diag318_handler(void) +{ + struct kvm_vm *vm; + struct kvm_run *run; + uint64_t reg; + uint64_t diag318_info; + + vm = vm_create_default(VCPU_ID, 0, guest_code); + vcpu_run(vm, VCPU_ID); + run = vcpu_state(vm, VCPU_ID); + + TEST_ASSERT(run->exit_reason == KVM_EXIT_S390_SIEIC, + "DIAGNOSE 0x0318 instruction was not intercepted"); + TEST_ASSERT(run->s390_sieic.icptcode == ICPT_INSTRUCTION, + "Unexpected intercept code: 0x%x", run->s390_sieic.icptcode); + TEST_ASSERT((run->s390_sieic.ipa & 0xff00) == IPA0_DIAG, + "Unexpected IPA0 code: 0x%x", (run->s390_sieic.ipa & 0xff00)); + + reg = (run->s390_sieic.ipa & 0x00f0) >> 4; + diag318_info = run->s.regs.gprs[reg]; + + TEST_ASSERT(diag318_info != 0, "DIAGNOSE 0x0318 info not set"); + + kvm_vm_free(vm); + + return diag318_info; +} + +uint64_t get_diag318_info(void) +{ + static uint64_t diag318_info; + static bool printed_skip; + + /* + * If KVM does not support diag318, then return 0 to + * ensure tests do not break. + */ + if (!kvm_check_cap(KVM_CAP_S390_DIAG318)) { + if (!printed_skip) { + fprintf(stdout, "KVM_CAP_S390_DIAG318 not supported. " + "Skipping diag318 test.\n"); + printed_skip = true; + } + return 0; + } + + /* + * If a test has previously requested the diag318 info, + * then don't bother spinning up a temporary VM again. + */ + if (!diag318_info) + diag318_info = diag318_handler(); + + return diag318_info; +} diff --git a/tools/testing/selftests/kvm/s390x/sync_regs_test.c b/tools/testing/selftests/kvm/s390x/sync_regs_test.c index 5731ccf34917..caf7b8859a94 100644 --- a/tools/testing/selftests/kvm/s390x/sync_regs_test.c +++ b/tools/testing/selftests/kvm/s390x/sync_regs_test.c @@ -20,6 +20,7 @@ #include "test_util.h" #include "kvm_util.h" +#include "diag318_test_handler.h" #define VCPU_ID 5 @@ -70,7 +71,7 @@ static void compare_sregs(struct kvm_sregs *left, struct kvm_sync_regs *right) #undef REG_COMPARE -#define TEST_SYNC_FIELDS (KVM_SYNC_GPRS|KVM_SYNC_ACRS|KVM_SYNC_CRS) +#define TEST_SYNC_FIELDS (KVM_SYNC_GPRS|KVM_SYNC_ACRS|KVM_SYNC_CRS|KVM_SYNC_DIAG318) #define INVALID_SYNC_FIELD 0x80000000 int main(int argc, char *argv[]) @@ -152,6 +153,12 @@ int main(int argc, char *argv[]) run->kvm_valid_regs = TEST_SYNC_FIELDS; run->kvm_dirty_regs = KVM_SYNC_GPRS | KVM_SYNC_ACRS; + + if (get_diag318_info() > 0) { + run->s.regs.diag318 = get_diag318_info(); + run->kvm_dirty_regs |= KVM_SYNC_DIAG318; + } + rv = _vcpu_run(vm, VCPU_ID); TEST_ASSERT(rv == 0, "vcpu_run failed: %d\n", rv); TEST_ASSERT(run->exit_reason == KVM_EXIT_S390_SIEIC, @@ -164,6 +171,9 @@ int main(int argc, char *argv[]) TEST_ASSERT(run->s.regs.acrs[0] == 1 << 11, "acr0 sync regs value incorrect 0x%x.", run->s.regs.acrs[0]); + TEST_ASSERT(run->s.regs.diag318 == get_diag318_info(), + "diag318 sync regs value incorrect 0x%llx.", + run->s.regs.diag318); vcpu_regs_get(vm, VCPU_ID, &regs); compare_regs(&regs, &run->s.regs); @@ -177,6 +187,7 @@ int main(int argc, char *argv[]) run->kvm_valid_regs = TEST_SYNC_FIELDS; run->kvm_dirty_regs = 0; run->s.regs.gprs[11] = 0xDEADBEEF; + run->s.regs.diag318 = 0x4B1D; rv = _vcpu_run(vm, VCPU_ID); TEST_ASSERT(rv == 0, "vcpu_run failed: %d\n", rv); TEST_ASSERT(run->exit_reason == KVM_EXIT_S390_SIEIC, @@ -186,6 +197,9 @@ int main(int argc, char *argv[]) TEST_ASSERT(run->s.regs.gprs[11] != 0xDEADBEEF, "r11 sync regs value incorrect 0x%llx.", run->s.regs.gprs[11]); + TEST_ASSERT(run->s.regs.diag318 != 0x4B1D, + "diag318 sync regs value incorrect 0x%llx.", + run->s.regs.diag318); kvm_vm_free(vm); -- 2.26.2

4 years, 4 months

4
12
0 0

Re: [PATCH bpf-next v3 1/5] selftests/bpf: xsk selftests framework

by Weqaar Janjua

On Fri, 27 Nov 2020 at 04:19, Yonghong Song <yhs(a)fb.com> wrote: > > > > On 11/26/20 1:22 PM, Weqaar Janjua wrote: > > On Thu, 26 Nov 2020 at 09:01, Björn Töpel <bjorn.topel(a)intel.com> wrote: > >> > >> On 2020-11-26 07:44, Yonghong Song wrote: > >>> > >> [...] > >>> > >>> What other configures I am missing? > >>> > >>> BTW, I cherry-picked the following pick from bpf tree in this experiment. > >>> commit e7f4a5919bf66e530e08ff352d9b78ed89574e6b (HEAD -> xsk) > >>> Author: Björn Töpel <bjorn.topel(a)intel.com> > >>> Date: Mon Nov 23 18:56:00 2020 +0100 > >>> > >>> net, xsk: Avoid taking multiple skbuff references > >>> > >> > >> Hmm, I'm getting an oops, unless I cherry-pick: > >> > >> 36ccdf85829a ("net, xsk: Avoid taking multiple skbuff references") > >> > >> *AND* > >> > >> 537cf4e3cc2f ("xsk: Fix umem cleanup bug at socket destruct") > >> > >> from bpf/master. > >> > > > > Same as Bjorn's findings ^^^, additionally applying the second patch > > 537cf4e3cc2f [PASS] all tests for me > > > > PREREQUISITES: [ PASS ] > > SKB NOPOLL: [ PASS ] > > SKB POLL: [ PASS ] > > DRV NOPOLL: [ PASS ] > > DRV POLL: [ PASS ] > > SKB SOCKET TEARDOWN: [ PASS ] > > DRV SOCKET TEARDOWN: [ PASS ] > > SKB BIDIRECTIONAL SOCKETS: [ PASS ] > > DRV BIDIRECTIONAL SOCKETS: [ PASS ] > > > > With the first patch alone, as soon as we enter DRV/Native NOPOLL mode > > kernel panics, whereas in your case NOPOLL tests were falling with > > packets being *lost* as per seqnum mismatch. > > > > Can you please test this out with both patches and let us know? > > I applied both the above patches in bpf-next as well as this patch set, > I still see failures. I am attaching my config file. Maybe you can take > a look at what is the issue. > Thanks for the config, can you please confirm the compiler version, and resource limits i.e. stack size, memory, etc.? Only NOPOLL tests are failing for you as I see it, do the same tests fail every time? I will need to spend some time debugging this to have a fix. Thanks, /Weqaar > > > >> Can I just run test_xsk.sh at tools/testing/selftests/bpf/ directory? > >> This will be easier than the above for bpf developers. If it does not > >> work, I would like to recommend to make it work. > >> > > yes test_xsk.shis self contained, will update the instructions in there with v4. > > That will be great. Thanks! > > > > > Thanks, > > /Weqaar > >> > >> Björn

4 years, 4 months

2
3
0 0

[PATCH v2 bpf-next 0/3] bpf: support module BTF in BTF display helpers

by Alan Maguire

This series aims to add support to bpf_snprintf_btf() and bpf_seq_printf_btf() allowing them to store string representations of module-specific types, as well as the kernel-specific ones they currently support. Patch 1 removes the btf_module_mutex, as since we will need to look up module BTF during BPF program execution, we don't want to risk sleeping in the various contexts in which BPF can run. The access patterns to the btf module list seem to conform to classic list RCU usage so with a few minor tweaks this seems workable. Patch 2 replaces the unused flags field in struct btf_ptr with an obj_id field, allowing the specification of the id of a BTF module. If the value is 0, the core kernel vmlinux is assumed to contain the type's BTF information. Otherwise the module with that id is used to identify the type. If the object-id based lookup fails, we again fall back to vmlinux BTF. Patch 3 is a selftest that uses veth (when built as a module) and a kprobe to display both a module-specific and kernel-specific type; both are arguments to veth_stats_rx(). Currently it looks up the module-specific type and object ids using libbpf; in future, these lookups will likely be supported directly in the BPF program via __builtin_btf_type_id(); but I need to determine a good test to determine if that builtin supports object ids. Changes since RFC - add patch to remove module mutex - modify to use obj_id instead of module name as identifier in "struct btf_ptr" (Andrii) Alan Maguire (3): bpf: eliminate btf_module_mutex as RCU synchronization can be used bpf: add module support to btf display helpers selftests/bpf: verify module-specific types can be shown via bpf_snprintf_btf include/linux/btf.h | 12 ++ include/uapi/linux/bpf.h | 13 ++- kernel/bpf/btf.c | 49 +++++--- kernel/trace/bpf_trace.c | 44 ++++++-- tools/include/uapi/linux/bpf.h | 13 ++- .../selftests/bpf/prog_tests/snprintf_btf_mod.c | 124 +++++++++++++++++++++ tools/testing/selftests/bpf/progs/bpf_iter.h | 2 +- tools/testing/selftests/bpf/progs/btf_ptr.h | 2 +- tools/testing/selftests/bpf/progs/veth_stats_rx.c | 72 ++++++++++++ 9 files changed, 292 insertions(+), 39 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/snprintf_btf_mod.c create mode 100644 tools/testing/selftests/bpf/progs/veth_stats_rx.c -- 1.8.3.1

4 years, 4 months

3
8
0 0

[PATCH v2] selftests/clone3: Fix build error

by Xingxing Su

When compiling the selftests with the -std=gnu99 option the build can fail with. Following build error: test_core.c: In function ‘test_cgcore_destroy’: test_core.c:87:2: error: ‘for’ loop initial declarations are only allowed in C99 mode for (int i = 0; i < 10; i++) { ^ test_core.c:87:2: note: use option -std=c99 or -std=gnu99 to compile Add -std=gnu99 to the clone3 selftest Makefile to fix this. Signed-off-by: Xingxing Su <suxingxing(a)loongson.cn> Acked-by: Christian Brauner <christian.brauner(a)ubuntu.com> --- tools/testing/selftests/clone3/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/clone3/Makefile b/tools/testing/selftests/clone3/Makefile index ef7564c..88354a8 100644 --- a/tools/testing/selftests/clone3/Makefile +++ b/tools/testing/selftests/clone3/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -CFLAGS += -g -I../../../../usr/include/ +CFLAGS += -g -std=gnu99 -I../../../../usr/include/ LDLIBS += -lcap TEST_GEN_PROGS := clone3 clone3_clear_sighand clone3_set_tid \ -- 1.8.3.1

4 years, 4 months

2
1
0 0

[PATCH] rseq/selftests: Fix MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ build error under other arch.

by Xingxing Su

Except arch x86, the function rseq_offset_deref_addv is not defined. The function test_membarrier_manager_thread call rseq_offset_deref_addv produces a build error. The RSEQ_ARCH_HAS_OFFSET_DEREF_ADD should contain all the code for the MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ. If the other Arch implements this feature, defined RSEQ_ARCH_HAS_OFFSET_DEREF_ADD in the header file to ensure that this feature is available. Following build errors: param_test.c: In function ‘test_membarrier_worker_thread’: param_test.c:1164:10: warning: implicit declaration of function ‘rseq_offset_deref_addv’ ret = rseq_offset_deref_addv(&args->percpu_list_ptr, ^~~~~~~~~~~~~~~~~~~~~~ /tmp/ccMj9yHJ.o: In function `test_membarrier_worker_thread': param_test.c:1164: undefined reference to `rseq_offset_deref_addv' param_test.c:1164: undefined reference to `rseq_offset_deref_addv' collect2: error: ld returned 1 exit status make: *** [/selftests/rseq/param_test_benchmark] Error 1 Signed-off-by: Xingxing Su <suxingxing(a)loongson.cn> --- tools/testing/selftests/rseq/param_test.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/rseq/param_test.c b/tools/testing/selftests/rseq/param_test.c index 3845890..699ad5f 100644 --- a/tools/testing/selftests/rseq/param_test.c +++ b/tools/testing/selftests/rseq/param_test.c @@ -1133,6 +1133,8 @@ static int set_signal_handler(void) return ret; } +/* Test MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU membarrier command. */ +#ifdef RSEQ_ARCH_HAS_OFFSET_DEREF_ADDV struct test_membarrier_thread_args { int stop; intptr_t percpu_list_ptr; @@ -1286,8 +1288,6 @@ void *test_membarrier_manager_thread(void *arg) return NULL; } -/* Test MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU membarrier command. */ -#ifdef RSEQ_ARCH_HAS_OFFSET_DEREF_ADDV void test_membarrier(void) { const int num_threads = opt_threads; -- 1.8.3.1

4 years, 4 months

3
2
0 0

[PATCH v3] self_tests/kvm: sync_regs test for diag318

by Collin Walling

The DIAGNOSE 0x0318 instruction, unique to s390x, is a privileged call that must be intercepted via SIE, handled in userspace, and the information set by the instruction is communicated back to KVM. To test the instruction interception, an ad-hoc handler is defined which simply has a VM execute the instruction and then userspace will extract the necessary info. The handler is defined such that the instruction invocation occurs only once. It is up to the caller to determine how the info returned by this handler should be used. The diag318 info is communicated from userspace to KVM via a sync_regs call. This is tested during a sync_regs test, where the diag318 info is requested via the handler, then the info is stored in the appropriate register in KVM via a sync registers call. If KVM does not support diag318, then the tests will print a message stating that diag318 was skipped, and the asserts will simply test against a value of 0. Signed-off-by: Collin Walling <walling(a)linux.ibm.com> --- v3 changes: no longer testing the reset code, as it is handled entirely via userspace. The respective reset tests have been removed --- tools/testing/selftests/kvm/Makefile | 2 +- .../kvm/include/s390x/diag318_test_handler.h | 13 +++ .../kvm/lib/s390x/diag318_test_handler.c | 82 +++++++++++++++++++ tools/testing/selftests/kvm/s390x/resets.c | 1 + .../selftests/kvm/s390x/sync_regs_test.c | 16 +++- 5 files changed, 112 insertions(+), 2 deletions(-) create mode 100644 tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h create mode 100644 tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile index 3d14ef77755e..426c78449044 100644 --- a/tools/testing/selftests/kvm/Makefile +++ b/tools/testing/selftests/kvm/Makefile @@ -36,7 +36,7 @@ endif LIBKVM = lib/assert.c lib/elf.c lib/io.c lib/kvm_util.c lib/sparsebit.c lib/test_util.c LIBKVM_x86_64 = lib/x86_64/processor.c lib/x86_64/vmx.c lib/x86_64/svm.c lib/x86_64/ucall.c lib/x86_64/handlers.S LIBKVM_aarch64 = lib/aarch64/processor.c lib/aarch64/ucall.c -LIBKVM_s390x = lib/s390x/processor.c lib/s390x/ucall.c +LIBKVM_s390x = lib/s390x/processor.c lib/s390x/ucall.c lib/s390x/diag318_test_handler.c TEST_GEN_PROGS_x86_64 = x86_64/cr4_cpuid_sync_test TEST_GEN_PROGS_x86_64 += x86_64/evmcs_test diff --git a/tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h b/tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h new file mode 100644 index 000000000000..b0ed71302722 --- /dev/null +++ b/tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h @@ -0,0 +1,13 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later + * + * Test handler for the s390x DIAGNOSE 0x0318 instruction. + * + * Copyright (C) 2020, IBM + */ + +#ifndef SELFTEST_KVM_DIAG318_TEST_HANDLER +#define SELFTEST_KVM_DIAG318_TEST_HANDLER + +uint64_t get_diag318_info(void); + +#endif diff --git a/tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c b/tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c new file mode 100644 index 000000000000..1e0b766efeb7 --- /dev/null +++ b/tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c @@ -0,0 +1,82 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Test handler for the s390x DIAGNOSE 0x0318 instruction. + * + * Copyright (C) 2020, IBM + */ + +#include "test_util.h" +#include "kvm_util.h" + +#define VCPU_ID 5 + +#define ICPT_INSTRUCTION 0x04 +#define IPA0_DIAG 0x8300 + +static void guest_code(void) +{ + uint64_t diag318_info = 0x12345678; + + asm volatile ("diag %0,0,0x318\n" : : "d" (diag318_info)); +} + +/* + * The DIAGNOSE 0x0318 instruction call must be handled via userspace. As such, + * we create an ad-hoc VM here to handle the instruction then extract the + * necessary data. It is up to the caller to decide what to do with that data. + */ +static uint64_t diag318_handler(void) +{ + struct kvm_vm *vm; + struct kvm_run *run; + uint64_t reg; + uint64_t diag318_info; + + vm = vm_create_default(VCPU_ID, 0, guest_code); + vcpu_run(vm, VCPU_ID); + run = vcpu_state(vm, VCPU_ID); + + TEST_ASSERT(run->exit_reason == KVM_EXIT_S390_SIEIC, + "DIAGNOSE 0x0318 instruction was not intercepted"); + TEST_ASSERT(run->s390_sieic.icptcode == ICPT_INSTRUCTION, + "Unexpected intercept code: 0x%x", run->s390_sieic.icptcode); + TEST_ASSERT((run->s390_sieic.ipa & 0xff00) == IPA0_DIAG, + "Unexpected IPA0 code: 0x%x", (run->s390_sieic.ipa & 0xff00)); + + reg = (run->s390_sieic.ipa & 0x00f0) >> 4; + diag318_info = run->s.regs.gprs[reg]; + + TEST_ASSERT(diag318_info != 0, "DIAGNOSE 0x0318 info not set"); + + kvm_vm_free(vm); + + return diag318_info; +} + +uint64_t get_diag318_info(void) +{ + static uint64_t diag318_info; + static bool printed_skip; + + /* + * If KVM does not support diag318, then return 0 to + * ensure tests do not break. + */ + if (!kvm_check_cap(KVM_CAP_S390_DIAG318)) { + if (!printed_skip) { + fprintf(stdout, "KVM_CAP_S390_DIAG318 not supported. " + "Skipping diag318 test.\n"); + printed_skip = true; + } + return 0; + } + + /* + * If a test has previously requested the diag318 info, + * then don't bother spinning up a temporary VM again. + */ + if (!diag318_info) + diag318_info = diag318_handler(); + + return diag318_info; +} diff --git a/tools/testing/selftests/kvm/s390x/resets.c b/tools/testing/selftests/kvm/s390x/resets.c index b143db6d8693..b3d7d4ac2d54 100644 --- a/tools/testing/selftests/kvm/s390x/resets.c +++ b/tools/testing/selftests/kvm/s390x/resets.c @@ -110,6 +110,7 @@ static void assert_clear(void) TEST_ASSERT(!memcmp(sync_regs->vrs, regs_null, sizeof(sync_regs->vrs)), "vrs0-15 == 0 (sync_regs)"); + } static void assert_initial_noclear(void) diff --git a/tools/testing/selftests/kvm/s390x/sync_regs_test.c b/tools/testing/selftests/kvm/s390x/sync_regs_test.c index 5731ccf34917..caf7b8859a94 100644 --- a/tools/testing/selftests/kvm/s390x/sync_regs_test.c +++ b/tools/testing/selftests/kvm/s390x/sync_regs_test.c @@ -20,6 +20,7 @@ #include "test_util.h" #include "kvm_util.h" +#include "diag318_test_handler.h" #define VCPU_ID 5 @@ -70,7 +71,7 @@ static void compare_sregs(struct kvm_sregs *left, struct kvm_sync_regs *right) #undef REG_COMPARE -#define TEST_SYNC_FIELDS (KVM_SYNC_GPRS|KVM_SYNC_ACRS|KVM_SYNC_CRS) +#define TEST_SYNC_FIELDS (KVM_SYNC_GPRS|KVM_SYNC_ACRS|KVM_SYNC_CRS|KVM_SYNC_DIAG318) #define INVALID_SYNC_FIELD 0x80000000 int main(int argc, char *argv[]) @@ -152,6 +153,12 @@ int main(int argc, char *argv[]) run->kvm_valid_regs = TEST_SYNC_FIELDS; run->kvm_dirty_regs = KVM_SYNC_GPRS | KVM_SYNC_ACRS; + + if (get_diag318_info() > 0) { + run->s.regs.diag318 = get_diag318_info(); + run->kvm_dirty_regs |= KVM_SYNC_DIAG318; + } + rv = _vcpu_run(vm, VCPU_ID); TEST_ASSERT(rv == 0, "vcpu_run failed: %d\n", rv); TEST_ASSERT(run->exit_reason == KVM_EXIT_S390_SIEIC, @@ -164,6 +171,9 @@ int main(int argc, char *argv[]) TEST_ASSERT(run->s.regs.acrs[0] == 1 << 11, "acr0 sync regs value incorrect 0x%x.", run->s.regs.acrs[0]); + TEST_ASSERT(run->s.regs.diag318 == get_diag318_info(), + "diag318 sync regs value incorrect 0x%llx.", + run->s.regs.diag318); vcpu_regs_get(vm, VCPU_ID, &regs); compare_regs(&regs, &run->s.regs); @@ -177,6 +187,7 @@ int main(int argc, char *argv[]) run->kvm_valid_regs = TEST_SYNC_FIELDS; run->kvm_dirty_regs = 0; run->s.regs.gprs[11] = 0xDEADBEEF; + run->s.regs.diag318 = 0x4B1D; rv = _vcpu_run(vm, VCPU_ID); TEST_ASSERT(rv == 0, "vcpu_run failed: %d\n", rv); TEST_ASSERT(run->exit_reason == KVM_EXIT_S390_SIEIC, @@ -186,6 +197,9 @@ int main(int argc, char *argv[]) TEST_ASSERT(run->s.regs.gprs[11] != 0xDEADBEEF, "r11 sync regs value incorrect 0x%llx.", run->s.regs.gprs[11]); + TEST_ASSERT(run->s.regs.diag318 != 0x4B1D, + "diag318 sync regs value incorrect 0x%llx.", + run->s.regs.diag318); kvm_vm_free(vm); -- 2.26.2

4 years, 4 months

3
4
0 0

[PATCH v3 0/6] mm/hmm/nouveau: add THP migration to migrate_vma_*

by Ralph Campbell

This series adds support for transparent huge page migration to migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers. Earlier versions were posted previously [1] and [2]. The patches apply cleanly to the linux-mm 5.10.0-rc2 tree. There are a lot of other THP patches being posted. I don't think there are any semantic conflicts but there may be some merge conflicts depending on the order Andrew applies these. Changes in v3: Sent the patch ("mm/thp: fix __split_huge_pmd_locked() for migration PMD") as a separate patch from this series. Rebased to linux-mm 5.10.0-rc2. Changes in v2: Added splitting a THP midway in the migration process: i.e., in migrate_vma_pages(). [1] https://lore.kernel.org/linux-mm/20200619215649.32297-1-rcampbell@nvidia.com [2] https://lore.kernel.org/linux-mm/20200902165830.5367-1-rcampbell@nvidia.com Ralph Campbell (6): mm/thp: add prep_transhuge_device_private_page() mm/migrate: move migrate_vma_collect_skip() mm: support THP migration to device private memory mm/thp: add THP allocation helper mm/hmm/test: add self tests for THP migration nouveau: support THP migration to private memory drivers/gpu/drm/nouveau/nouveau_dmem.c | 289 +++++++++++----- drivers/gpu/drm/nouveau/nouveau_svm.c | 11 +- drivers/gpu/drm/nouveau/nouveau_svm.h | 3 +- include/linux/gfp.h | 10 + include/linux/huge_mm.h | 12 + include/linux/memremap.h | 9 + include/linux/migrate.h | 2 + lib/test_hmm.c | 437 +++++++++++++++++++++---- lib/test_hmm_uapi.h | 3 + mm/huge_memory.c | 147 +++++++-- mm/memcontrol.c | 25 +- mm/memory.c | 10 +- mm/memremap.c | 4 +- mm/migrate.c | 429 +++++++++++++++++++----- mm/rmap.c | 2 +- tools/testing/selftests/vm/hmm-tests.c | 404 +++++++++++++++++++++++ 16 files changed, 1522 insertions(+), 275 deletions(-) -- 2.20.1

4 years, 4 months

6
24
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror