July 2024 - Linux-kselftest-mirror

[PATCH bpf-next v1 0/3] add bpf_file_d_path helper and selftests

by Lin Yikai

v1: - patch 2: - [1/2] add bpf_file_d_path helper - [2/2] add selftest to it Hi, we are looking to add the "bpf_file_d_path" helper, used to retrieve the path from a struct file object. bpf_file_d_path(void *file, char *dst, u32 size); It's worth noting that the "file" parameter is defined as "void*" type. * Our problems * Previously, we encountered issues on some user-space operating systems(OS): 1.Difficulty using vmlinux.h (1) The OS lacks support for bpftool. We can not use: "bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h". Bpftool need a separate complex cross-compilation environment to build. (2) Many duplicate definitions between OS and vmlinux.h. (3) The vmlinux.h size is large (2.8MB on arm64/Android), causing increased ebpf prog size and user space consumption. 2.The "struct file" has many internal variables and definitions, and maybe change along with Linux version iterations, making it hard to copy it to OS. * Benefits of this commit * 1.There is no need to include vmlinux.h or redefine "struct file". For example, with bpf on kprobe, we can directly pass param "(void*)PT_REGS_PARM1(pt_regs)" to "bpf_file_d_path" helper in order to retrieve the path. Appreciate your review and assistance. Thank you. Yikai Lin Yikai (2): bpf: Add bpf_file_d_path helper selftests/bpf:Adding test for bpf_file_d_path helper include/uapi/linux/bpf.h | 20 +++ kernel/trace/bpf_trace.c | 34 ++++++ tools/include/uapi/linux/bpf.h | 20 +++ .../selftests/bpf/prog_tests/file_d_path.c | 115 ++++++++++++++++++ .../selftests/bpf/progs/test_file_d_path.c | 32 +++++ 5 files changed, 221 insertions(+) create mode 100644 tools/testing/selftests/bpf/prog_tests/file_d_path.c create mode 100644 tools/testing/selftests/bpf/progs/test_file_d_path.c -- 2.34.1

3 months, 3 weeks

3
4
0 0

[PATCH v1] selftests/ftrace: Skip test for optimized probes on PowerPC if Secure Boot is enabled

by Akanksha J N

Currently while accessing debugfs with Secure Boot enabled on PowerPC, it is causing the kprobe_opt_types.tc test to fail. Below is the snippet of the error: +++ grep kernel_clone /sys/kernel/debug/kprobes/list grep: /sys/kernel/debug/kprobes/list: Operation not permitted ++ PROBE= + '[' 2 -ne 0 ']' + kill -s 37 7595 ++ SIG_RESULT=1 + eval_result 1 + case $1 in + prlog ' [\033[31mFAIL\033[0m]' + newline='\n' + '[' ' [\033[31mFAIL\033[0m]' = -n ']' + printf ' [\033[31mFAIL\033[0m]\n' [FAIL] This is happening when secure boot is enabled, as it enables lockdown by default. With lockdown, access to certain debug features and filesystems like debugfs may be restricted or completely disabled. To fix this, modify the test to check for Secure Boot status using lsprop /proc/device-tree/ibm,secure-boot. And, skip execution of the test on PowerPC if Secure Boot is enabled (00000002). With this patch, test skips as unsupported: === Ftrace unit tests === [1] Register/unregister optimized probe [UNSUPPORTED] Signed-off-by: Akanksha J N <akanksha(a)linux.ibm.com> --- .../selftests/ftrace/test.d/kprobe/kprobe_opt_types.tc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_types.tc b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_types.tc index 9f5d99328086..87e2f81e46b8 100644 --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_types.tc +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_types.tc @@ -10,6 +10,11 @@ x86_64) arm*) ;; ppc*) +lsprop_output=$(lsprop /proc/device-tree/ibm,secure-boot) +if echo "$lsprop_output" | grep -q "00000002"; then + echo "Secure Boot is enabled on PowerPC." + exit_unsupported +fi ;; *) echo "Please implement other architecture here" -- 2.39.3 (Apple Git-146)

3 months, 3 weeks

2
1
0 0

[PATCH v3 0/4] selftest: x86: improve tests

by Muhammad Usama Anjum

Changes since v1: - Correct the description of patches with what improvements they are bringing and why they are required Changes since v2: - Update descriptions of patches and add output before/after Muhammad Usama Anjum (4): selftests: x86: check_initial_reg_state: remove manual counting and increase maintainability selftests: x86: corrupt_xstate_header: remove manual counting and increase maintainability selftests: x86: fsgsbase_restore: remove manual counting and increase maintainability selftests: x86: entry_from_vm86: remove manual counting and increase maintainability .../selftests/x86/check_initial_reg_state.c | 24 ++-- .../selftests/x86/corrupt_xstate_header.c | 30 +++-- tools/testing/selftests/x86/entry_from_vm86.c | 109 ++++++++-------- .../testing/selftests/x86/fsgsbase_restore.c | 117 +++++++++--------- 4 files changed, 139 insertions(+), 141 deletions(-) -- 2.39.2

3 months, 3 weeks

2
8
0 0

Re: [PATCH] kselftest/arm64: Add coresight test

by James Clark

+cc linux-kselftest(a)vger.kernel.org On 19/07/2024 11:21 am, Jeremy Szu wrote: > > > James Clark 於 7/17/24 10:48 PM 寫道: >> >> >> On 16/07/2024 3:06 am, Jeremy Szu wrote: >>> Hi James, >>> >>> Thank you for your reply. >>> >>> James Clark 於 7/12/24 5:01 PM 寫道: >>>> >>>> >>>> On 11/07/2024 7:03 pm, Catalin Marinas wrote: >>>>> On Wed, Jul 10, 2024 at 02:27:32PM +0800, Jeremy Szu wrote: >>>>>> Add a script to test the coresight functionalities by performing the >>>>>> perf test 'coresight'. >>>>>> >>>>>> The script checks the prerequisites and launches a bundle of >>>>>> Coresight-related tests with a 180-second timeout. >>>>>> >>>> >>>> Hi Jeremy, >>>> >>>> On the whole I'm not sure running the Perf tests under kself tests >>>> is a good fit. We're already running all the Perf tests in various >>>> CIs, so this is going to duplicate effort. Especially with setup and >>>> parsing of the results output. >>>> >>>> There is also no clean line between what's a kernel issue and whats >>>> a Perf issue when these fail. >>>> >>>> And thirdly why only run the Coresight tests? Most of the Perf tests >>>> test some part of the kernel, so if we were going to do this I think >>>> it would make sense to make some kind of proper harness and run them >>>> all. I have some recollection that someone said it might be >>>> something we could do, but I can't remember the discussion. >>> >>> The idea I'm trying to pursue is to use arm64 kselftest to run as >>> many test cases as possible for ARM SoCs across different designs and >>> distros. I believe it could provide an alert if there is an issue, >>> whether it originates from userspace or kernel, similar to how perf >>> is used in other categories. >>> >>> I'm not sure if all perf tests could be counted in soc >>> (selftests/arm64) category such as some tests may target to storage, >>> memory or devices. I >> >> Could we not put the Perf tests in .../selftests/perf.sh, then it >> doesn't really matter which subsystem they're targeting and we can run >> all the Perf tests? >> > > The .../sefltests/ seems for the kselftest framework only, not sure if > having a new .../selftests/perf will make more sense? > Yeah that sounds better, but it probably requires changing the title of the patch to "[RFC] kselftest: Run Perf tests under kselftest" or something like that. >>> could replace 'arm64/coresight' with 'arm64/perf' if it makes more >>> sense. I believe it could help users verify functionality more >>> conveniently. >>> >>>> >>>> Ignoring the main issue above I've left some comments about this >>>> patch inline below: >>>> >>>>>> Signed-off-by: Jeremy Szu <jszu(a)nvidia.com> >>>>> >>>>> I have not idea how to test coresight, so adding Suzuki as well. >>>>> >>>>>> --- >>>>>> tools/testing/selftests/arm64/Makefile | 2 +- >>>>>> .../selftests/arm64/coresight/Makefile | 5 +++ >>>>>> .../selftests/arm64/coresight/coresight.sh | 40 >>>>>> +++++++++++++++++++ >>>>>> .../selftests/arm64/coresight/settings | 1 + >>>>>> 4 files changed, 47 insertions(+), 1 deletion(-) >>>>>> create mode 100644 tools/testing/selftests/arm64/coresight/Makefile >>>>>> create mode 100755 >>>>>> tools/testing/selftests/arm64/coresight/coresight.sh >>>>>> create mode 100644 tools/testing/selftests/arm64/coresight/settings >>>>>> >>>>>> diff --git a/tools/testing/selftests/arm64/Makefile >>>>>> b/tools/testing/selftests/arm64/Makefile >>>>>> index 28b93cab8c0dd..2b788d7bab22d 100644 >>>>>> --- a/tools/testing/selftests/arm64/Makefile >>>>>> +++ b/tools/testing/selftests/arm64/Makefile >>>>>> @@ -4,7 +4,7 @@ >>>>>> ARCH ?= $(shell uname -m 2>/dev/null || echo not) >>>>>> ifneq (,$(filter $(ARCH),aarch64 arm64)) >>>>>> -ARM64_SUBTARGETS ?= tags signal pauth fp mte bti abi >>>>>> +ARM64_SUBTARGETS ?= tags signal pauth fp mte bti abi coresight >>>>>> else >>>>>> ARM64_SUBTARGETS := >>>>>> endif >>>>>> diff --git a/tools/testing/selftests/arm64/coresight/Makefile >>>>>> b/tools/testing/selftests/arm64/coresight/Makefile >>>>>> new file mode 100644 >>>>>> index 0000000000000..1cc8c1f2a997e >>>>>> --- /dev/null >>>>>> +++ b/tools/testing/selftests/arm64/coresight/Makefile >>>>>> @@ -0,0 +1,5 @@ >>>>>> +# SPDX-License-Identifier: GPL-2.0 >>>>>> + >>>>>> +TEST_PROGS := coresight.sh >>>>>> + >>>>>> +include ../../lib.mk >>>>>> diff --git a/tools/testing/selftests/arm64/coresight/coresight.sh >>>>>> b/tools/testing/selftests/arm64/coresight/coresight.sh >>>>>> new file mode 100755 >>>>>> index 0000000000000..e550957cf593b >>>>>> --- /dev/null >>>>>> +++ b/tools/testing/selftests/arm64/coresight/coresight.sh >>>>>> @@ -0,0 +1,40 @@ >>>>>> +#!/bin/bash >>>>>> +# SPDX-License-Identifier: GPL-2.0 >>>>>> + >>>>>> +skip() { >>>>>> + echo "SKIP: $1" >>>>>> + exit 4 >>>>>> +} >>>>>> + >>>>>> +fail() { >>>>>> + echo "FAIL: $1" >>>>>> + exit 255 >>>>>> +} >>>>>> + >>>>>> +is_coresight_supported() { >>>>>> + if [ -d "/sys/bus/coresight/devices" ]; then >>>>>> + return 0 >>>>>> + fi >>>>>> + return 255 >>>>>> +} >>>> >>>> The Perf coresight tests already have a skip mechanism built in so >>>> can we rely on that instead of duplicating it here? There are also >>>> other scenarios for skipping like Perf not linked with OpenCSD which >>>> aren't covered here. >>>> >>> >>> Will it return the different error code to indicate if it's failed to >>> be executed or the coresight is not supported? >>> >> >> I think the exit code is only used for more serious errors. For things >> like missing tests, SKIP and FAIL it still exits with 0 but you have >> to grep for the strings. Actually for a missing test it prints nothing >> and exits 0. >> >>>>> + >>>>>> +if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then >>>>>> + [ "$(id -u)" -ne 0 ] && \ >>>>>> + skip "this test must be run as root." >>>>>> + which perf >/dev/null 2>&1 || \ >>>>>> + skip "perf is not installed." >>>>>> + perf test list 2>&1 | grep -qi 'coresight' || \ >>>>>> + skip "perf doesn't support testing coresight." >>>> >>>> Can this be an error instead? The coresight tests were added in 5.10 >>>> and I don't think new kselftest needs to support such old kernels. >>>> This skip risks turning an error with installing the tests into a >>>> silent failure. >>>> >>>> Also as far as I know a lot of distros will refuse to open Perf >>>> unless it matches the kernel version if it was installed from the >>>> package manager, so we don't need to worry about old versions. >>>> >>> >>> The idea to skip it here is because I thought either a distro >>> (custom) kernel doesn't enable the kconfig or the distro built the >>> perf with CORESIGHT=0. >>> >>> I could make it as an error and put it after "is_coresight_support" >>> if it makes more sense. >>> >> >> But the Coresight test already checks these things, which is my point. >> You can grep for "SKIP" which it will print for any case where the >> coresight test can't be run due to some missing config. >> > > Oh, I guess you mean to rely on something like the `perf list cs_etm | > grep -q cs_etm || exit 2`. Yes, that makes more sense. > If we're leaning towards running all the Perf tests then none of this is required anymore. This is another example of why it's better to run them all. We can't realistically hard code a kself test with loads of logic for each Perf subtest when Perf will happily run all the tests on it's own without any extra work. >>>>>> + is_coresight_supported || \ >>>>>> + skip "coresight is not supported." >>>>>> + >>>>>> + cmd_output=$(perf test -vv 'coresight' 2>&1) >>>>>> + perf_ret=$? >>>>>> + >>>>>> + if [ $perf_ret -ne 0 ]; then >>>>>> + fail "perf command returns non-zero." >>>>>> + elif [[ $cmd_output == *"FAILED!"* ]]; then >>>>>> + echo $cmd_output >>>> >>>> It's probably helpful to print cmd_output in both failure cases. >>>> >>> >>> ok, will do. >>> >>>>>> + fail "perf test 'arm coresight' test failed!" > > I think I should remove the `is_coresight_supported` there and checks > the output as a "else" to see if the test is PASS or SKIP. Does it make > sense to you? > Same as above applies, the only thing that's really required is parsing for "FAILED". >>>>>> + fi >>>>>> +fi >>>>>> diff --git a/tools/testing/selftests/arm64/coresight/settings >>>>>> b/tools/testing/selftests/arm64/coresight/settings >>>>>> new file mode 100644 >>>>>> index 0000000000000..a953c96aa16e1 >>>>>> --- /dev/null >>>>>> +++ b/tools/testing/selftests/arm64/coresight/settings >>>>>> @@ -0,0 +1 @@ >>>>>> +timeout=180 >>>> >>>> I timed 331 seconds on n1sdp, and probably even longer on Juno. >>>> >>>> It doesn't need to run for this long and it's an issue with the >>>> tests, but currently that's how long it takes so the timeout needs >>>> to be longer. >>>> >>> >>> ok, will extend it to 600. >>> >>>>>> -- >>>>>> 2.34.1 >>>>>

3 months, 3 weeks

1
0
0 0

[PATCH bpf-next v3 0/5] use network helpers, part 9

by Geliang Tang

From: Geliang Tang <tanggeliang(a)kylinos.cn> v3: - patch 2: - clear errno before connect_to_fd_opts. - print err logs in run_test. - set err to -1 when fd >= 0. - patch 3: - drop "int err". v2: - update patch 2 as Martin suggested. This is the 9th part of series "use network helpers" all BPF selftests wide. Patches 1-2 update network helpers interfaces suggested by Martin. Patch 3 adds a new helper connect_to_addr_str() as Martin suggested instead of adding connect_fd_to_addr_str(). Patch 4 uses this newly added helper in make_client(). Patch 5 uses make_client() in sk_lookup and drop make_socket(). Geliang Tang (5): selftests/bpf: Drop type of connect_to_fd_opts selftests/bpf: Drop must_fail from network_helper_opts selftests/bpf: Add connect_to_addr_str helper selftests/bpf: Use connect_to_addr_str in sk_lookup selftests/bpf: Drop make_socket in sk_lookup tools/testing/selftests/bpf/network_helpers.c | 65 ++++++-------- tools/testing/selftests/bpf/network_helpers.h | 5 +- .../selftests/bpf/prog_tests/bpf_tcp_ca.c | 2 +- .../selftests/bpf/prog_tests/cgroup_v1v2.c | 16 ++-- .../selftests/bpf/prog_tests/sk_lookup.c | 84 ++++--------------- 5 files changed, 56 insertions(+), 116 deletions(-) -- 2.43.0

3 months, 3 weeks

2
8
0 0

[PATCH v2 0/2] kselftest/alsa: Diagnostic improvements

by Mark Brown

The first patch fixes unstable naming of tests due to probe ordering not being stable, the second just provides a bit more information. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Changes in v2: - Switch to using ID rather than longame. - Log the PCM ID too. - Link to v1: https://lore.kernel.org/r/20240711-alsa-kselftest-board-name-v1-1-ab5cf2dbb… --- Mark Brown (2): kselftest/alsa: Use card name rather than number in test names kselftest/alsa: Log the PCM ID in pcm-test tools/testing/selftests/alsa/mixer-test.c | 98 +++++++++++++++++++------------ tools/testing/selftests/alsa/pcm-test.c | 68 +++++++++++++++------ 2 files changed, 108 insertions(+), 58 deletions(-) --- base-commit: f2661062f16b2de5d7b6a5c42a9a5c96326b8454 change-id: 20240711-alsa-kselftest-board-name-e4a1add4cfa0 Best regards, -- Mark Brown <broonie(a)kernel.org>

3 months, 3 weeks

2
3
0 0

KUnit file naming conventions (was Re: [GIT PULL] execve updates for v6.11-rc1)

by Kees Cook

On Tue, Jul 16, 2024 at 01:10:41PM -0700, Linus Torvalds wrote: > On Mon, 15 Jul 2024 at 09:21, Kees Cook <kees(a)kernel.org> wrote: > > > > fs/exec.c | 49 ++++++++-- > > fs/exec_test.c | 141 ++++++++++++++++++++++++++++ > > I've pulled this, but *PLEASE* don't do this. > > This screws up my workflow of just using tab-completion for filenames. > As a result, I absolutely abhor anybody who uses the same base-name > for different things. > > No, this is not the first time it happens, and it won't be the last. > And we had that same horrific pattern for fs/binfmt_elf_test.c from > before, and I didn't notice because it's not a core file to me, and I > seldom actually edit it. > > I would suggest that people use the patterns from lib/, which is > admittedly a bit schizophrenic in that you can either use > "lib/kunit/*.c" (probably preferred) or "lib/test_xyz.c". > > (Other subsystems use a "tests" subdirectory, so we do have a lot of > different ways to deal with this). > > Any of those models will keep the unit testing parts clearly separate, > and not mess up basic command line workflows. > > But do *not* use this "*_test.c" naming model. It's the worst of all > possible worlds. > > Please? Oh, sure, no problem! I have no attachment to this convention at all; I was trying to follow the Kunit docs: https://docs.kernel.org/dev-tools/kunit/style.html#test-file-and-module-nam… If I look at the existing naming, it's pretty scattered: $ git grep '^static struct kunit_suite\b' | cut -d: -f1 | sort -u /test/* 7 /tests/* 47 *-test.[ch] 27 *_test.[ch] 27 test-*.c 1 test_*.c 10 *-kunit.c 1 *_kunit.c 17 kunit-*.c 2 kunit_*.c 1 Should we go with "put it all under a 'tests' subdirectory" ? So for fs/exec_test.c and fs/binfmt_elf_test.c, perhaps fs/tests/exec.c and fs/tests/binfmt_elf.c respectively? And for the lib/*_kunit.c files, use lib/tests/*.c ? Then we can update the docs, etc. -- Kees Cook

3 months, 3 weeks

2
3
0 0

[PATCH] Documentation: KUnit: Update filename best practices

by Kees Cook

Based on feedback from Linus[1], change the suggested file naming for KUnit tests. Link: https://lore.kernel.org/lkml/CAHk-=wgim6pNiGTBMhP8Kd3tsB7_JTAuvNJ=XYd3wPvvk… [1] Signed-off-by: Kees Cook <kees(a)kernel.org> --- Cc: David Gow <davidgow(a)google.com> Cc: Brendan Higgins <brendan.higgins(a)linux.dev> Cc: Rae Moar <rmoar(a)google.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: linux-kselftest(a)vger.kernel.org Cc: kunit-dev(a)googlegroups.com Cc: linux-doc(a)vger.kernel.org --- Documentation/dev-tools/kunit/style.rst | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst index b6d0d7359f00..761dee3f89ca 100644 --- a/Documentation/dev-tools/kunit/style.rst +++ b/Documentation/dev-tools/kunit/style.rst @@ -188,15 +188,20 @@ For example, a Kconfig entry might look like: Test File and Module Names ========================== -KUnit tests can often be compiled as a module. These modules should be named -after the test suite, followed by ``_test``. If this is likely to conflict with -non-KUnit tests, the suffix ``_kunit`` can also be used. - -The easiest way of achieving this is to name the file containing the test suite -``<suite>_test.c`` (or, as above, ``<suite>_kunit.c``). This file should be -placed next to the code under test. +Whether a KUnit test is compiled as a separate module or via an +``#include`` in a core kernel source file, the files should be named +after the test suite, followed by ``_test``, and live in a ``tests`` +subdirectory to avoid conflicting with regular modules or the core kernel +source file names (e.g. for tab-completion). If this would conflict with +non-KUnit tests, the suffix ``_kunit`` can be used instead. + +So for the common case, name the file containing the test suite +``tests/<suite>_test.c`` (or, if needed, ``tests/<suite>_kunit.c``). The +``tests`` directory should be placed at the same level as the +code under test. For example, tests for ``lib/string.c`` live in +``lib/tests/string_test.c``. If the suite name contains some or all of the name of the test's parent directory, it may make sense to modify the source filename to reduce redundancy. -For example, a ``foo_firmware`` suite could be in the ``foo/firmware_test.c`` +For example, a ``foo_firmware`` suite could be in the ``tests/foo/firmware_test.c`` file. -- 2.34.1

3 months, 3 weeks

3
4
0 0

[PATCH v2] selftests/mm: Skip test for non-LPA2 and non-LVA systems

by Dev Jain

Post my improvement of the test: https://lore.kernel.org/all/20240522070435.773918-3-dev.jain@arm.com/ The test begins to fail on 4k and 16k pages, on non-LPA2 systems. To reduce noise in the CI systems, let us skip the test when higher address space is not implemented. v1->v2: - Guard with ifdeffery to prevent compiler warning on other arches Signed-off-by: Dev Jain <dev.jain(a)arm.com> Reviewed-by: Ryan Roberts <ryan.roberts(a)arm.com> --- The patch applies on linux-next. tools/testing/selftests/mm/va_high_addr_switch.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/mm/va_high_addr_switch.c b/tools/testing/selftests/mm/va_high_addr_switch.c index fa7eabfaf841..896b3f73fc53 100644 --- a/tools/testing/selftests/mm/va_high_addr_switch.c +++ b/tools/testing/selftests/mm/va_high_addr_switch.c @@ -293,6 +293,20 @@ static int run_test(struct testcase *test, int count) return ret; } +#ifdef __aarch64__ +/* Check if userspace VA > 48 bits */ +static int high_address_present(void) +{ + void *ptr = mmap((void *)(1UL << 50), 1, PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0); + if (ptr == MAP_FAILED) + return 0; + + munmap(ptr, 1); + return 1; +} +#endif + static int supported_arch(void) { #if defined(__powerpc64__) @@ -300,7 +314,7 @@ static int supported_arch(void) #elif defined(__x86_64__) return 1; #elif defined(__aarch64__) - return 1; + return high_address_present(); #else return 0; #endif -- 2.34.1

3 months, 3 weeks

1
0
0 0

[PATCH v4 0/3] Allow userspace to change ID_AA64PFR1_EL1

by Shaoqin Huang

Hi guys, This is another try to allow userspace to change ID_AA64PFR1_EL1, and we want to give userspace the ability to control the visible feature set for a VM, which could be used by userspace in such a way to transparently migrate VMs. The patch series have three part: The first patch disable those fields which KVM doesn't know how to handle, so KVM will only expose value 0 of those fields to the guest. The second patch allow userspace to change ID_AA64PFR1_EL1, it allow as much as possible fields to be writable, except some special fields which is still not writable. The third patch adds the kselftest to test if userspace can change the ID_AA64PFR1_EL1. Besides, I also noticed there is another patch [1] which try to make the ID_AA64PFR1_EL1 writable. This patch [1] is try to enable GCS on baremental, and add GCS support for the guest. What I understand is if we have GCS support on baremental, it will be clear to how to handle them in KVM. And same for other fields like NMI, THE, DF2, MTEX.. I'm still not confident about the correctness of this patch series, but I've try my best to understand each of the fields. And follow Marc's comments to tweak this patch series. The question confuse me a lot is that should we allow those fields (NMI, GCS, THE, DF2, MTEX..) which KVM doesn't know how to handle writable? Baremental doesn't know about them, and the ftr_id_aa64pfr1[] doesn't know about them. I follow the comment "I should handle all 15 fields", so I allow them writable because they're disabled in the register read accessor, and their value will alwyas be 0, the userspace can write to it but only value 0. If I did anything wrong, please point me out. Thanks a lot. [1] [PATCH v9 13/39] KVM: arm64: Manage GCS registers for guests https://lore.kernel.org/all/20240625-arm64-gcs-v9-13-0f634469b8f0@kernel.or… Changelog: ---------- v3 -> v4: * Add a new patch to disable some feature which KVM doesn't know how to handle in the register accessor. * Handle all the fields in the register. * Fixes a small cnt issue in kselftest. v2 -> v3: * Give more description about why only part of the fields can be writable. * Updated the writable mask by referring the latest ARM spec. v1 -> v2: * Tackling the full register instead of single field. * Changing the patch title and commit message. RFCv1 -> v1: * Fix the compilation error. * Delete the machine specific information and make the description more generable. RFCv1: https://lore.kernel.org/all/20240612023553.127813-1-shahuang@redhat.com/ v1: https://lore.kernel.org/all/20240617075131.1006173-1-shahuang@redhat.com/ v2: https://lore.kernel.org/all/20240618063808.1040085-1-shahuang@redhat.com/ v3: https://lore.kernel.org/all/20240628060454.1936886-2-shahuang@redhat.com/ Shaoqin Huang (3): KVM: arm64: Disable fields that KVM doesn't know how to handle in ID_AA64PFR1_EL1 KVM: arm64: Allow userspace to change ID_AA64PFR1_EL1 KVM: selftests: aarch64: Add writable test for ID_AA64PFR1_EL1 arch/arm64/kvm/sys_regs.c | 13 ++++++++++- .../selftests/kvm/aarch64/set_id_regs.c | 23 ++++++++++++++++--- 2 files changed, 32 insertions(+), 4 deletions(-) -- 2.40.1

3 months, 3 weeks

1
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror July 2024