October 2023 - Linux-kselftest-mirror

[PATCH 0/5] selftests/nolibc: various build improvements

by Thomas Weißschuh

With the out-of-tree builds it's possible do incremental tests fairly fast: $ time ./run-tests.sh i386: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success x86_64: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success arm64: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success arm: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success mips: 160 test(s): 159 passed, 1 skipped, 0 failed => status: warning ppc: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success ppc64: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success ppc64le: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success riscv: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success s390: 160 test(s): 159 passed, 1 skipped, 0 failed => status: warning loongarch: 160 test(s): 159 passed, 1 skipped, 0 failed => status: warning real 3m11.735s user 4m20.354s sys 1m11.880s This is with an incremental kernel rebuild and testrun inside qemu. Note: "selftests/nolibc: use qemu-system-ppc64 also for ppc64le" was already submitted standalone but I included it here again for easier testing and review. Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Thomas Weißschuh (5): selftests/nolibc: use qemu-system-ppc64 also for ppc64le selftests/nolibc: use EFI -bios for LoongArch qemu selftests/nolibc: anchor paths in $(srcdir) if possible selftests/nolibc: support out-of-tree builds selftests/nolibc: generate config automatically tools/testing/selftests/nolibc/Makefile | 36 +++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 13 deletions(-) --- base-commit: d423dcd4ac21041618ab83455c09440d76dbc099 change-id: 20231010-nolibc-out-of-tree-b6684c6cf0e3 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

7 months, 1 week

4
14
0 0

[PATCH 00/21] arm64: Support for 2023 DPISA extensions

by Mark Brown

This series enables support for the data processing extensions in the newly released 2023 architecture, this is mainly support for 8 bit floating point formats. Most of the extensions only introduce new instructions and therefore only require hwcaps but there is a new EL0 visible control register FPMR used to control the 8 bit floating point formats, we need to manage traps for this and context switch it. The sharing of floating point save code between the host and guest kernels slightly complicates the introduction of KVM support, we first introduce host support with some placeholders for KVM then replace those with the actual KVM support. I've not added test coverage for ptrace, I've got a not quite finished test program which exercises all the FP ptrace interfaces and their interactions together, my plan is to cover it there rather than add another tiny test program that duplicates the boilerplace for tracing a target and doesn't actually run the traced program. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Mark Brown (21): arm64/sysreg: Add definition for ID_AA64PFR2_EL1 arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion for DDI0601 2023-09 arm64/sysreg: Add definition for ID_AA64ISAR3_EL1 arm64/sysreg: Add definition for ID_AA64FPFR0_EL1 arm64/sysreg: Update ID_AA64SMFR0_EL1 definition for DDI0601 2023-09 arm64/sysreg: Update SCTLR_EL1 for DDI0601 2023-09 arm64/sysreg: Update HCRX_EL2 definition for DDI0601 2023-09 arm64/sysreg: Add definition for FPMR arm64/cpufeature: Hook new identification registers up to cpufeature arm64/fpsimd: Enable host kernel access to FPMR arm64/fpsimd: Support FEAT_FPMR arm64/signal: Add FPMR signal handling arm64/ptrace: Expose FPMR via ptrace KVM: arm64: Add newly allocated ID registers to register descriptions KVM: arm64: Support FEAT_FPMR for guests arm64/hwcap: Define hwcaps for 2023 DPISA features kselftest/arm64: Handle FPMR context in generic signal frame parser kselftest/arm64: Add basic FPMR test kselftest/arm64: Add 2023 DPISA hwcap test coverage KVM: arm64: selftests: Document feature registers added in 2023 extensions KVM: arm64: selftests: Teach get-reg-list about FPMR Documentation/arch/arm64/elf_hwcaps.rst | 49 +++++ arch/arm64/include/asm/cpu.h | 3 + arch/arm64/include/asm/cpufeature.h | 5 + arch/arm64/include/asm/fpsimd.h | 2 + arch/arm64/include/asm/hwcap.h | 15 ++ arch/arm64/include/asm/kvm_arm.h | 4 +- arch/arm64/include/asm/kvm_host.h | 3 + arch/arm64/include/asm/processor.h | 2 + arch/arm64/include/uapi/asm/hwcap.h | 15 ++ arch/arm64/include/uapi/asm/sigcontext.h | 8 + arch/arm64/kernel/cpufeature.c | 72 +++++++ arch/arm64/kernel/cpuinfo.c | 18 ++ arch/arm64/kernel/fpsimd.c | 13 ++ arch/arm64/kernel/ptrace.c | 42 ++++ arch/arm64/kernel/signal.c | 59 ++++++ arch/arm64/kvm/fpsimd.c | 19 +- arch/arm64/kvm/hyp/include/hyp/switch.h | 7 +- arch/arm64/kvm/sys_regs.c | 17 +- arch/arm64/tools/cpucaps | 1 + arch/arm64/tools/sysreg | 153 ++++++++++++++- include/uapi/linux/elf.h | 1 + tools/testing/selftests/arm64/abi/hwcap.c | 217 +++++++++++++++++++++ tools/testing/selftests/arm64/signal/.gitignore | 1 + .../arm64/signal/testcases/fpmr_siginfo.c | 82 ++++++++ .../selftests/arm64/signal/testcases/testcases.c | 8 + .../selftests/arm64/signal/testcases/testcases.h | 1 + tools/testing/selftests/kvm/aarch64/get-reg-list.c | 11 +- 27 files changed, 810 insertions(+), 18 deletions(-) --- base-commit: 05d3ef8bba77c1b5f98d941d8b2d4aeab8118ef1 change-id: 20231003-arm64-2023-dpisa-2f3d25746474 Best regards, -- Mark Brown <broonie(a)kernel.org>

7 months, 1 week

1
21
0 0

[linux-next:master] [selftests] 5b45a75377: kernel-selftests.uevent.uevent_filtering.fail

by kernel test robot

Hello, kernel test robot noticed "kernel-selftests.uevent.uevent_filtering.fail" on: commit: 5b45a753776be5d21cf395ec97e81c9187fbeaca ("selftests: uevent filtering: fix return on error in uevent_listener") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master [test failed on linux-next/master 2030579113a1b1b5bfd7ff24c0852847836d8fd1] in testcase: kernel-selftests version: kernel-selftests-x86_64-60acb023-1_20230329 with following parameters: group: group-03 compiler: gcc-12 test machine: 36 threads 1 sockets Intel(R) Core(TM) i9-10980XE CPU @ 3.00GHz (Cascade Lake) with 32G memory (please refer to attached dmesg/kmsg for entire log/backtrace) we also noticed this issue does not always happen. as below, we saw 15 failures out of 50 runs. however, parent keeps passing. 37013b557b7f39e6 5b45a753776be5d21cf395ec97e ---------------- --------------------------- fail:runs %reproduction fail:runs | | | :50 30% 15:50 kernel-selftests.uevent.uevent_filtering.fail If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <oliver.sang(a)intel.com> | Closes: https://lore.kernel.org/oe-lkp/202310261454.46082aaa-oliver.sang@intel.com TAP version 13 1..1 # timeout set to 300 # selftests: uevent: uevent_filtering # TAP version 13 # 1..1 # # Starting 1 tests from 1 test cases. # # RUN global.uevent_filtering ... # add@/devices/virtual/mem/fullACTION=addDEVPATH=/devices/virtual/mem/fullSUBSYSTEM=memSYNTH_UUID=0MAJOR=1MINOR=7DEVNAME=fullDEVMODE=0666SEQNUM=3532 # add@/devices/virtual/mem/fullACTION=addDEVPATH=/devices/virtual/mem/fullSUBSYSTEM=memSYNTH_UUID=0MAJOR=1MINOR=7DEVNAME=fullDEVMODE=0666SEQNUM=3546 # add@/devices/virtual/mem/fullACTION=addDEVPATH=/devices/virtual/mem/fullSUBSYSTEM=memSYNTH_UUID=0MAJOR=1MINOR=7DEVNAME=fullDEVMODE=0666SEQNUM=3556 # add@/devices/virtual/mem/fullACTION=addDEVPATH=/devices/virtual/mem/fullSUBSYSTEM=memSYNTH_UUID=0MAJOR=1MINOR=7DEVNAME=fullDEVMODE=0666SEQNUM=3585 # add@/devices/virtual/mem/fullACTION=addDEVPATH=/devices/virtual/mem/fullSUBSYSTEM=memSYNTH_UUID=0MAJOR=1MINOR=7DEVNAME=fullDEVMODE=0666SEQNUM=3595 # No buffer space available - Failed to receive uevent # # uevent_filtering.c:479:uevent_filtering:Expected 0 (0) == ret (-1) # # uevent_filtering: Test failed at step #10 # # FAIL global.uevent_filtering # not ok 1 global.uevent_filtering # # FAILED: 0 / 1 tests passed. # # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0 not ok 1 selftests: uevent: uevent_filtering # exit=1 The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20231026/202310261454.46082aaa-oliv… -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

7 months, 1 week

2
1
0 0

[PATCH v2] kunit: Warn if tests are slow

by Maxime Ripard

Kunit recently gained support to setup attributes, the first one being the speed of a given test, then allowing to filter out slow tests. A slow test is defined in the documentation as taking more than one second. There's an another speed attribute called "super slow" but whose definition is less clear. Add support to the test runner to check the test execution time, and report tests that should be marked as slow but aren't. Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- To: Brendan Higgins <brendan.higgins(a)linux.dev> To: David Gow <davidgow(a)google.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Rae Moar <rmoar(a)google.com> Cc: linux-kselftest(a)vger.kernel.org Cc: kunit-dev(a)googlegroups.com Cc: linux-kernel(a)vger.kernel.org Changes from v1: - Split the patch out of the series - Change to trigger the warning only if the runtime is twice the threshold (Jani, Rae) - Split the speed check into a separate function (Rae) - Link: https://lore.kernel.org/all/20230911-kms-slow-tests-v1-0-d3800a69a1a1@kerne… --- lib/kunit/test.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/lib/kunit/test.c b/lib/kunit/test.c index 49698a168437..a1d5dd2bf87d 100644 --- a/lib/kunit/test.c +++ b/lib/kunit/test.c @@ -372,6 +372,25 @@ void kunit_init_test(struct kunit *test, const char *name, char *log) } EXPORT_SYMBOL_GPL(kunit_init_test); +#define KUNIT_SPEED_SLOW_THRESHOLD_S 1 + +static void kunit_run_case_check_speed(struct kunit *test, + struct kunit_case *test_case, + struct timespec64 duration) +{ + enum kunit_speed speed = test_case->attr.speed; + + if (duration.tv_sec < (2 * KUNIT_SPEED_SLOW_THRESHOLD_S)) + return; + + if (speed == KUNIT_SPEED_VERY_SLOW || speed == KUNIT_SPEED_SLOW) + return; + + kunit_warn(test, + "Test should be marked slow (runtime: %lld.%09lds)", + duration.tv_sec, duration.tv_nsec); +} + /* * Initializes and runs test case. Does not clean up or do post validations. */ @@ -379,6 +398,8 @@ static void kunit_run_case_internal(struct kunit *test, struct kunit_suite *suite, struct kunit_case *test_case) { + struct timespec64 start, end; + if (suite->init) { int ret; @@ -390,7 +411,13 @@ static void kunit_run_case_internal(struct kunit *test, } } + ktime_get_ts64(&start); + test_case->run_case(test); + + ktime_get_ts64(&end); + + kunit_run_case_check_speed(test, test_case, timespec64_sub(end, start)); } static void kunit_case_internal_cleanup(struct kunit *test) -- 2.41.0

7 months, 1 week

3
5
0 0

[PATCH v7 0/8] Add Intel VT-d nested translation (part 1/2)

by Yi Liu

This is the first part to add Intel VT-d nested translation based on IOMMUFD nesting infrastructure. As the iommufd nesting infrastructure series[1], iommu core supports new ops to allocate domains with user data. For nesting, the user data is vendor-specific, IOMMU_HWPT_DATA_VTD_S1 is defined for the Intel VT-d stage-1 page table, it will be used in the stage-1 domain allocation path. struct iommu_hwpt_vtd_s1 is defined to pass user_data for the Intel VT-d stage-1 domain allocation. This series does not have the cache invalidation path, it would be added in part 2/2. The first Intel platform supporting nested translation is Sapphire Rapids which, unfortunately, has a hardware errata [2] requiring special treatment. This errata happens when a stage-1 page table page (either level) is located in a stage-2 read-only region. In that case the IOMMU hardware may ignore the stage-2 RO permission and still set the A/D bit in stage-1 page table entries during page table walking. A flag IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17 is introduced to report this errata to userspace. With that restriction the user should either disable nested translation to favor RO stage-2 mappings or ensure no RO stage-2 mapping to enable nested translation. Intel-iommu driver is armed with necessary checks to prevent such mix in patch8 of this series. Qemu currently does add RO mappings though. The vfio agent in Qemu simply maps all valid regions in the GPA address space which certainly includes RO regions e.g. vbios. In reality we don't know a usage relying on DMA reads from the BIOS region. Hence finding a way to skip RO regions (e.g. via a discard manager) in Qemu might be an acceptable tradeoff. The actual change needs more discussion in Qemu community. For now we just hacked Qemu to test. Complete code can be found in [3], corresponding QEMU could can be found in [4]. [1] https://lore.kernel.org/linux-iommu/20231024150609.46884-1-yi.l.liu@intel.c… [2] https://www.intel.com/content/www/us/en/content-details/772415/content-deta… [3] https://github.com/yiliu1765/iommufd/tree/iommufd_nesting [4] https://github.com/yiliu1765/qemu/tree/zhenzhong/wip/iommufd_nesting_rfcv1 Change log: v7: - Rebase on top of latest iommufd nesting part 1/2 - Add the nested_parent flag in patch 07 and sanitize it for nested domain allocation (Baolu) - Fail the nested domain allocation if dirty tracking flag is set v6: https://lore.kernel.org/linux-iommu/20231020093246.17015-1-yi.l.liu@intel.c… - Add Kevin's r-b for patch 1 and 8 - Drop Kevin's r-b for patch 7 - Address comments from Kevin - Split the VT-d nesting series into two parts 1/2 and 2/2 v5: https://lore.kernel.org/linux-iommu/20230921075431.125239-1-yi.l.liu@intel.… - Add Kevin's r-b for patch 2, 3 ,5 8, 10 - Drop enforce_cache_coherency callback from the nested type domain ops (Kevin) - Remove duplicate agaw check in patch 04 (Kevin) - Remove duplicate domain_update_iommu_cap() in patch 06 (Kevin) - Check parent's force_snooping to set pgsnp in the pasid entry (Kevin) - uapi data structure check (Kevin) - Simplify the errata handling as user can allocate nested parent domain v4: https://lore.kernel.org/linux-iommu/20230724111335.107427-1-yi.l.liu@intel.… - Remove ascii art tables (Jason) - Drop EMT (Tina, Jason) - Drop MTS and related definitions (Kevin) - Rename macro IOMMU_VTD_PGTBL_ to IOMMU_VTD_S1_ (Kevin) - Rename struct iommu_hwpt_intel_vtd_ to iommu_hwpt_vtd_ (Kevin) - Rename struct iommu_hwpt_intel_vtd to iommu_hwpt_vtd_s1 (Kevin) - Put the vendor specific hwpt alloc data structure before enuma iommu_hwpt_type (Kevin) - Do not trim the higher page levels of S2 domain in nested domain attachment as the S2 domain may have been used independently. (Kevin) - Remove the first-stage pgd check against the maximum address of s2_domain as hw can check it anyhow. It makes sense to check every pfns used in the stage-1 page table. But it cannot make it. So just leave it to hw. (Kevin) - Split the iotlb flush part into an order of uapi, helper and callback implementation (Kevin) - Change the policy of VT-d nesting errata, disallow RO mapping once a domain is used as parent domain of a nested domain. This removes the nested_users counting. (Kevin) - Minor fix for "make htmldocs" v3: https://lore.kernel.org/linux-iommu/20230511145110.27707-1-yi.l.liu@intel.c… - Further split the patches into an order of adding helpers for nested domain, iotlb flush, nested domain attachment and nested domain allocation callback, then report the hw_info to userspace. - Add batch support in cache invalidation from userspace - Disallow nested translation usage if RO mappings exists in stage-2 domain due to errata on readonly mappings on Sapphire Rapids platform. v2: https://lore.kernel.org/linux-iommu/20230309082207.612346-1-yi.l.liu@intel.… - The iommufd infrastructure is split to be separate series. v1: https://lore.kernel.org/linux-iommu/20230209043153.14964-1-yi.l.liu@intel.c… Regards, Yi Liu Lu Baolu (5): iommu/vt-d: Extend dmar_domain to support nested domain iommu/vt-d: Add helper for nested domain allocation iommu/vt-d: Add helper to setup pasid nested translation iommu/vt-d: Add nested domain allocation iommu/vt-d: Disallow read-only mappings to nest parent domain Yi Liu (3): iommufd: Add data structure for Intel VT-d stage-1 domain allocation iommu/vt-d: Make domain attach helpers to be extern iommu/vt-d: Set the nested domain to a device drivers/iommu/intel/Makefile | 2 +- drivers/iommu/intel/iommu.c | 88 +++++++++++++++++---------- drivers/iommu/intel/iommu.h | 46 ++++++++++++-- drivers/iommu/intel/nested.c | 109 ++++++++++++++++++++++++++++++++++ drivers/iommu/intel/pasid.c | 112 +++++++++++++++++++++++++++++++++++ drivers/iommu/intel/pasid.h | 2 + include/uapi/linux/iommufd.h | 42 ++++++++++++- 7 files changed, 362 insertions(+), 39 deletions(-) create mode 100644 drivers/iommu/intel/nested.c -- 2.34.1

7 months, 1 week

3
17
0 0

Purpose of gen_tar

by Marcos Paulo de Souza

Hi, while testing a new patch on the livepatch kselftests, I was testing the gen_tar target and I figured that we only copy the resulting binaries to the final tar file. Per the kselftests documentation[1], the gen_tar target is used to package the tests to run "on different systems". But what if the different system has different libraries/library versions? Wouldn't it be a problem? This question came when I was working to build the livepatch modules as part of the kselftests testing suit. The plan was to just package the test scripts/programs/modules and then run the tests on a different system, likewise a different SLE version. Since the kernel would be different in this case, I expected that gen_tar would copy the module source files so they can be compiled on the target system. While the current approach can work when the selftests rely solely on shell scripts(cpufreq, kexec), those who compile userspace binaries (cgroup, alsa, sched, ...) may not work. Am I missing something? Is gen_tar only meant to copy the tests to be run on systems with the same libraries or with the libraries with the exactly the same version? Thanks in advance, Marcos [1]: https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html

7 months, 1 week

3
2
0 0

[PATCH-cgroup 0/4] cgroup/cpuset: Improve CPU isolation in isolated partitions

by Waiman Long

Isolated cpuset partition can currently be created to contain an exclusive set of CPUs not used in other cgroups and with load balancing disabled to reduce interference from the scheduler. The main purpose of this isolated partition type is to dynamically emulate what can be done via the "isolcpus" boot command line option, specifically the default domain flag. One effect of the "isolcpus" option is to remove the isolated CPUs from the cpumasks of unbound workqueues since running work functions in an isolated CPU can be a major source of interference. Changing the unbound workqueue cpumasks can be done at run time by writing an appropriate cpumask without the isolated CPUs to /sys/devices/virtual/workqueue/cpumask. So one can set up an isolated cpuset partition and then write to the cpumask sysfs file to achieve similar level of CPU isolation. However, this manual process can be error prone. This patch series implements automatic exclusion of isolated CPUs from unbound workqueue cpumasks when an isolated cpuset partition is created and then adds those CPUs back when the isolated partition is destroyed. There are also other places in the kernel that look at the HK_FLAG_DOMAIN cpumask or other HK_FLAG_* cpumasks and exclude the isolated CPUs from certain actions to further reduce interference. CPUs in an isolated cpuset partition will not be able to avoid those interferences yet. That may change in the future as the need arises. Waiman Long (4): workqueue: Add workqueue_unbound_exclude_cpumask() to exclude CPUs from wq_unbound_cpumask selftests/cgroup: Minor code cleanup and reorganization of test_cpuset_prs.sh cgroup/cpuset: Keep track of CPUs in isolated partitions cgroup/cpuset: Take isolated CPUs out of workqueue unbound cpumask Documentation/admin-guide/cgroup-v2.rst | 10 +- include/linux/workqueue.h | 2 +- kernel/cgroup/cpuset.c | 237 +++++++++++++----- kernel/workqueue.c | 42 +++- .../selftests/cgroup/test_cpuset_prs.sh | 209 +++++++++------ 5 files changed, 350 insertions(+), 150 deletions(-) -- 2.39.3

7 months, 1 week

2
15
0 0

[PATCH] iommu/vt-d: Enhance capability check for nested parent domain allocation

by Yi Liu

This adds the scalable mode check before allocating the nested parent domain as checking nested capability is not enough. User may turn off scalable mode which also means no nested support even if the hardware supports it. Fixes: c97d1b20d383 ("iommu/vt-d: Add domain_alloc_user op") Signed-off-by: Yi Liu <yi.l.liu(a)intel.com> --- v1: Based on Joao's dirty page tracking v6 https://github.com/jpemartins/linux/commits/iommufd-v6 --- drivers/iommu/intel/iommu.c | 2 +- drivers/iommu/intel/iommu.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index eb92a201cc0b..65f46f1347e6 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -4090,7 +4090,7 @@ intel_iommu_domain_alloc_user(struct device *dev, u32 flags) if (!iommu) return ERR_PTR(-ENODEV); - if ((flags & IOMMU_HWPT_ALLOC_NEST_PARENT) && !ecap_nest(iommu->ecap)) + if ((flags & IOMMU_HWPT_ALLOC_NEST_PARENT) && !nested_supported(iommu)) return ERR_PTR(-EOPNOTSUPP); dirty_tracking = (flags & IOMMU_HWPT_ALLOC_DIRTY_TRACKING); diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 3bb569146229..cc7301579773 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -544,6 +544,8 @@ enum { ecap_pasid((iommu)->ecap)) #define ssads_supported(iommu) (sm_supported(iommu) && \ ecap_slads((iommu)->ecap)) +#define nested_supported(iommu) (sm_supported(iommu) && \ + ecap_nest((iommu)->ecap)) struct pasid_entry; struct pasid_state_entry; -- 2.34.1

7 months, 1 week

4
3
0 0

[PATCH v6 00/10] iommufd: Add nesting infrastructure (part 1/2)

by Yi Liu

Nested translation is a hardware feature that is supported by many modern IOMMU hardwares. It has two stages of address translations to get access to the physical address. A stage-1 translation table is owned by userspace (e.g. by a guest OS), while a stage-2 is owned by kernel. Any change to a stage-1 translation table should be followed by an IOTLB invalidation. Take Intel VT-d as an example, the stage-1 translation table is guest I/O page table. As the below diagram shows, the guest I/O page table pointer in GPA (guest physical address) is passed to host and be used to perform a stage-1 translation. Along with it, a modification to present mappings in the guest I/O page table should be followed by an IOTLB invalidation. .-------------. .---------------------------. | vIOMMU | | Guest I/O page table | | | '---------------------------' .----------------/ | PASID Entry |--- PASID cache flush --+ '-------------' | | | V | | I/O page table pointer in GPA '-------------' Guest ------| Shadow |---------------------------|-------- v v v Host .-------------. .------------------------. | pIOMMU | | FS for GIOVA->GPA | | | '------------------------' .----------------/ | | PASID Entry | V (Nested xlate) '----------------\.----------------------------------. | | | SS for GPA->HPA, unmanaged domain| | | '----------------------------------' '-------------' Where: - FS = First stage page tables - SS = Second stage page tables <Intel VT-d Nested translation> In IOMMUFD, all the translation tables are tracked by hw_pagetable (hwpt) and each hwpt is backed by an iommu_domain allocated from an iommu driver. So in this series hw_pagetable and iommu_domain means the same thing if no special note. IOMMUFD has already supported allocating hw_pagetable linked with an IOAS. However, a nesting case requires IOMMUFD to allow allocating hw_pagetable with driver specific parameters and interface to sync stage-1 IOTLB as user owns the stage-1 translation table. This series is based on the iommu hw info reporting series [1] and nested parent domain allocation [2]. It first extends domain_alloc_user to allocate hwpt with user data by allowing the IOMMUFD internal infrastructure to accept user_data and parent hwpt, relaying the user_data/parent to the iommu core to allocate IOMMU_DOMAIN_NESTED. And it then extends the IOMMU_HWPT_ALLOC ioctl to accept user data and a parent hwpt ID. Note that this series is the part-1 set of a two-part nesting series. It does not include the cache invalidation interface, which will be added in the part 2. Complete code can be found in [3], it is on top of Joao's dirty page tracking v6 series and fix patches. QEMU could can be found in [4]. At last, this is a team work together with Nicolin Chen, Lu Baolu. Thanks them for the help. ^_^. Look forward to your feedbacks. [1] https://lore.kernel.org/linux-iommu/20230818101033.4100-1-yi.l.liu@intel.co… - merged [2] https://lore.kernel.org/linux-iommu/20230928071528.26258-1-yi.l.liu@intel.c… - merged [3] https://github.com/yiliu1765/iommufd/tree/iommufd_nesting [4] https://github.com/yiliu1765/qemu/tree/zhenzhong/wip/iommufd_nesting_rfcv1 Change log: v6: - Rebase on top of Joao's dirty tracking series: https://lore.kernel.org/linux-iommu/20231024135109.73787-1-joao.m.martins@o… - Rebase on top of the enforce_cache_coherency removal patch: https://lore.kernel.org/linux-iommu/ZTcAhwYjjzqM0A5M@Asurada-Nvidia/ - Add parent and user_data check in iommu driver before the driver actually supports the two input. This can make better bisect support, the change is in patch 02. v5: https://lore.kernel.org/linux-iommu/20231020091946.12173-1-yi.l.liu@intel.c… - Split the iommufd nesting series into two parts of alloc_user and invalidation (Jason) - Split IOMMUFD_OBJ_HW_PAGETABLE to IOMMUFD_OBJ_HWPT_PAGING/_NESTED, and do the same with the structures/alloc()/abort()/destroy(). Reworked the selftest accordingly too. (Jason) - Move hwpt/data_type into struct iommu_user_data from standalone op arguments. (Jason) - Rename hwpt_type to be data_type, the HWPT_TYPE to be HWPT_ALLOC_DATA, _TYPE_DEFAULT to be _ALLOC_DATA_NONE (Jason, Kevin) - Rename iommu_copy_user_data() to iommu_copy_struct_from_user() (Kevin) - Add macro to the iommu_copy_struct_from_user() to calculate min_size (Jason) - Fix two bugs spotted by ZhaoYan v4: https://lore.kernel.org/linux-iommu/20230921075138.124099-1-yi.l.liu@intel.… - Separate HWPT alloc/destroy/abort functions between user-managed HWPTs and kernel-managed HWPTs - Rework invalidate uAPI to be a multi-request array-based design - Add a struct iommu_user_data_array and a helper for driver to sanitize and copy the entry data from user space invalidation array - Add a patch fixing TEST_LENGTH() in selftest program - Drop IOMMU_RESV_IOVA_RANGES patches - Update kdoc and inline comments - Drop the code to add IOMMU_RESV_SW_MSI to kernel-managed HWPT in nested translation, this does not change the rule that resv regions should only be added to the kernel-managed HWPT. The IOMMU_RESV_SW_MSI stuff will be added in later series as it is needed only by SMMU so far. v3: https://lore.kernel.org/linux-iommu/20230724110406.107212-1-yi.l.liu@intel.… - Add new uAPI things in alphabetical order - Pass in "enum iommu_hwpt_type hwpt_type" to op->domain_alloc_user for sanity, replacing the previous op->domain_alloc_user_data_len solution - Return ERR_PTR from domain_alloc_user instead of NULL - Only add IOMMU_RESV_SW_MSI to kernel-managed HWPT in nested translation (Kevin) - Add IOMMU_RESV_IOVA_RANGES to report resv iova ranges to userspace hence userspace is able to exclude the ranges in the stage-1 HWPT (e.g. guest I/O page table). (Kevin) - Add selftest coverage for the new IOMMU_RESV_IOVA_RANGES ioctl - Minor changes per Kevin's inputs v2: https://lore.kernel.org/linux-iommu/20230511143844.22693-1-yi.l.liu@intel.c… - Add union iommu_domain_user_data to include all user data structures to avoid passing void * in kernel APIs. - Add iommu op to return user data length for user domain allocation - Rename struct iommu_hwpt_alloc::data_type to be hwpt_type - Store the invalidation data length in iommu_domain_ops::cache_invalidate_user_data_len - Convert cache_invalidate_user op to be int instead of void - Remove @data_type in struct iommu_hwpt_invalidate - Remove out_hwpt_type_bitmap in struct iommu_hw_info hence drop patch 08 of v1 v1: https://lore.kernel.org/linux-iommu/20230309080910.607396-1-yi.l.liu@intel.… Thanks, Yi Liu Jason Gunthorpe (2): iommufd: Rename IOMMUFD_OBJ_HW_PAGETABLE to IOMMUFD_OBJ_HWPT_PAGING iommufd/device: Wrap IOMMUFD_OBJ_HWPT_PAGING-only configurations Lu Baolu (1): iommu: Add IOMMU_DOMAIN_NESTED Nicolin Chen (6): iommufd: Derive iommufd_hwpt_paging from iommufd_hw_pagetable iommufd: Share iommufd_hwpt_alloc with IOMMUFD_OBJ_HWPT_NESTED iommufd: Add a nested HW pagetable object iommu: Add iommu_copy_struct_from_user helper iommufd/selftest: Add nested domain allocation for mock domain iommufd/selftest: Add coverage for IOMMU_HWPT_ALLOC with nested HWPTs Yi Liu (1): iommu: Pass in parent domain with user_data to domain_alloc_user op drivers/iommu/intel/iommu.c | 7 +- drivers/iommu/iommufd/device.c | 157 +++++++--- drivers/iommu/iommufd/hw_pagetable.c | 271 +++++++++++++----- drivers/iommu/iommufd/iommufd_private.h | 73 +++-- drivers/iommu/iommufd/iommufd_test.h | 18 ++ drivers/iommu/iommufd/main.c | 10 +- drivers/iommu/iommufd/selftest.c | 151 ++++++++-- drivers/iommu/iommufd/vfio_compat.c | 6 +- include/linux/iommu.h | 72 ++++- include/uapi/linux/iommufd.h | 31 +- tools/testing/selftests/iommu/iommufd.c | 120 ++++++++ .../selftests/iommu/iommufd_fail_nth.c | 3 +- tools/testing/selftests/iommu/iommufd_utils.h | 31 +- 13 files changed, 768 insertions(+), 182 deletions(-) -- 2.34.1

7 months, 1 week

5
29
0 0

[PATCH 0/2] um: kunit: Add Clang support for CONFIG_GCOV

by Michał Winiarski

Clang uses a different set of CLI args for coverage, and the output needs to be processed by a different set of tools. Update the Makefile and add an example of usage in kunit docs. Michał Winiarski (2): arch: um: Add Clang coverage support Documentation: kunit: Add clang UML coverage example Documentation/dev-tools/kunit/running_tips.rst | 11 +++++++++++ arch/um/Makefile-skas | 5 +++++ 2 files changed, 16 insertions(+) -- 2.42.0

7 months, 1 week

3
5
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror October 2023