iommufd gives userspace the capability to manipulate iommu subsytem.
e.g. DMA map/unmap etc. In the near future, it will support iommu nested
translation. Different platform vendors have different implementations for
the nested translation. For example, Intel VT-d supports using guest I/O
page table as the stage-1 translation table. This requires guest I/O page
table be compatible with hardware IOMMU. So before set up nested translation,
userspace needs to know the hardware iommu information to understand the
nested translation requirements.
This series reports the iommu hardware information for a given device
which has been bound to iommufd. It is preparation work for userspace to
allocate hwpt for given device. Like the nested translation support[1].
This series introduces an iommu op to report the iommu hardware info,
and an ioctl IOMMU_GET_HW_INFO is added to report such hardware info to
user. enum iommu_hw_info_type is defined to differentiate the iommu hardware
info reported to user hence user can decode them. This series adds the
framework for iommu hw info reporting, and adds the vtd implementation. The
complete code is available in [1].
[1] https://github.com/yiliu1765/iommufd/tree/iommufd_hw_info-v8
Change log:
v8:
- Updated the uAPI by allowing a 0 value at the input @data_len
- Changed to always report the kernel supported data length instead of the
length that kernel filled in the user space buffer
- Updated uAPI doc accordingly
- Add one more selftest for 0 value @data_len and also check the output @data_len
with the size kernel supports
- Fix the usage of clear_user()
- Rebase on top of Jason's for-next branch (base: 65aaca1 iommufd: Remove iommufd_ref_to_users())
- Include the vtd hw_info implementation from vtd nesting series
https://lore.kernel.org/r/20230724111335.107427-12-yi.l.liu@intel.com
v7: https://lore.kernel.org/linux-iommu/20230811071501.4126-1-yi.l.liu@intel.co…
- Use clear_user() (Jason)
- Add fail_nth for hw_ifo (Jason)
v6: https://lore.kernel.org/linux-iommu/20230808153510.4170-1-yi.l.liu@intel.co…
- Add Jingqi's comment on patch 02
- Add Baolu's r-b to patch 03
- Address Jason's comment on patch 03
v5: https://lore.kernel.org/linux-iommu/20230803143144.200945-1-yi.l.liu@intel.…
- Return hw_info_type in the .hw_info op, hence drop hw_info_type field in iommu_ops (Kevin)
- Add Jason's r-b for patch 01
- Address coding style comments from Jason and Kevin w.r.t. patch 02, 03 and 04
v4: https://lore.kernel.org/linux-iommu/20230724105936.107042-1-yi.l.liu@intel.…
- Rename ioctl to IOMMU_GET_HW_INFO and structure to iommu_hw_info
- Move the iommufd_get_hw_info handler to main.c
- Place iommu_hw_info prior to iommu_hwpt_alloc
- Update the function namings accordingly
- Update uapi kdocs
v3: https://lore.kernel.org/linux-iommu/20230511143024.19542-1-yi.l.liu@intel.c…
- Add r-b from Baolu
- Rename IOMMU_HW_INFO_TYPE_DEFAULT to be IOMMU_HW_INFO_TYPE_NONE to
better suit what it means
- Let IOMMU_DEVICE_GET_HW_INFO succeed even the underlying iommu driver
does not have driver-specific data to report per below remark.
https://lore.kernel.org/kvm/ZAcwJSK%2F9UVI9LXu@nvidia.com/
v2: https://lore.kernel.org/linux-iommu/20230309075358.571567-1-yi.l.liu@intel.…
- Drop patch 05 of v1 as it is already covered by other series
- Rename the capability info to be iommu hardware info
v1: https://lore.kernel.org/linux-iommu/20230209041642.9346-1-yi.l.liu@intel.co…
Regards,
Yi Liu
Lu Baolu (1):
iommu: Add new iommu op to get iommu hardware information
Nicolin Chen (1):
iommufd/selftest: Add coverage for IOMMU_GET_HW_INFO ioctl
Yi Liu (3):
iommu: Move dev_iommu_ops() to private header
iommufd: Add IOMMU_GET_HW_INFO
iommu/vt-d: Implement hw_info for iommu capability query
drivers/iommu/intel/iommu.c | 19 +++++
drivers/iommu/iommu-priv.h | 11 +++
drivers/iommu/iommufd/device.c | 73 ++++++++++++++++++
drivers/iommu/iommufd/iommufd_private.h | 1 +
drivers/iommu/iommufd/iommufd_test.h | 9 +++
drivers/iommu/iommufd/main.c | 3 +
drivers/iommu/iommufd/selftest.c | 16 ++++
include/linux/iommu.h | 20 +++--
include/uapi/linux/iommufd.h | 74 +++++++++++++++++++
tools/testing/selftests/iommu/iommufd.c | 30 +++++++-
.../selftests/iommu/iommufd_fail_nth.c | 4 +
tools/testing/selftests/iommu/iommufd_utils.h | 56 ++++++++++++++
12 files changed, 304 insertions(+), 12 deletions(-)
--
2.34.1
Hi,
This patch series aims to improve the PMU event filter settings with a cleaner
and more organized structure and adds several test cases related to PMU event
filters.
These changes help to ensure that KVM's PMU event filter functions as expected
in all supported use cases.
Any feedback or suggestions are greatly appreciated.
Sincerely,
Jinrong Liang
Changes log:
v6:
- Rebased to 74c2185c5b74(tag: kvm-x86-next-2023.08.02);
- Use TEST_ASSERT_EQ() instead of ASSERT_EQ();
- Fix a bug about x86 properties for Intel PMU in patch v5;
v5:
https://lore.kernel.org/kvm/20230720114714.34079-1-cloudliang@tencent.com/T/
Jinrong Liang (6):
KVM: selftests: Add x86 properties for Intel PMU in processor.h
KVM: selftests: Drop the return of remove_event()
KVM: selftests: Introduce __kvm_pmu_event_filter to improved event
filter settings
KVM: selftests: Add test cases for unsupported PMU event filter input
values
KVM: selftests: Test if event filter meets expectations on fixed
counters
KVM: selftests: Test gp event filters don't affect fixed event filters
.../selftests/kvm/include/x86_64/processor.h | 5 +
.../kvm/x86_64/pmu_event_filter_test.c | 317 ++++++++++++------
2 files changed, 228 insertions(+), 94 deletions(-)
base-commit: 74c2185c5b74fd0ae91133ad5afe8684f6a02b91
--
2.39.3
Add parameter descriptions to struct kunit_attr header for the
parameters attr_default and print.
Fixes: 39e92cb1e4a1 ("kunit: Add test attributes API structure")
Reported-by: kernel test robot <lkp(a)intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202308180127.VD7YRPGa-lkp@intel.com/
Signed-off-by: Rae Moar <rmoar(a)google.com>
---
lib/kunit/attributes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/kunit/attributes.c b/lib/kunit/attributes.c
index 5e3034b6be99..1b512f7e1838 100644
--- a/lib/kunit/attributes.c
+++ b/lib/kunit/attributes.c
@@ -30,6 +30,8 @@ enum print_ops {
* attribute value
* @filter: function to indicate whether a given attribute value passes a
* filter
+ * @attr_default: default attribute value used during filtering
+ * @print: value of enum print_ops to indicate when to print attribute
*/
struct kunit_attr {
const char *name;
base-commit: 582eb3aeed2d06b122fba95518b84506d3d4ceb9
--
2.42.0.rc1.204.g551eb34607-goog
I ran all kernel selftests on some test machine, and stumbled upon
cachestat failing (among others).
Those patches fix the cachestat test compilation and run on older
kernels.
Also I found that the but-last test (on a normal file) fails when run on
a tmpfs mounted directory, as it happens on an initramfs-only system, or
when the current directory happens to be /dev/shm or /tmp:
# Create/open tmpfilecachestat
# Cachestat call returned 0
# Using cachestat: Cached: 4, Dirty: 4, Writeback: 0, Evicted: 0, Recently Evicted: 0
# Cachestat call (after fsync) returned 0
# Using cachestat: Cached: 4, Dirty: 4, Writeback: 0, Evicted: 0, Recently Evicted: 0
# Number of dirty should be zero after fsync.
not ok 6 cachestat fails with normal file
That same test binary succeeds on the same machine right afterwards if
the current directory is changed to an ext4 filesystem.
I don't really know if this is expected, and whether we should try to
figure out if the test file lives on a tmpfs filesystem, or whether the
test itself is not strict enough, and requires more "flushing"
(drop_caches?) to cover tmpfs directories as well.
Any ideas how to fix this would be appreciated.
Cheers,
Andre
Andre Przywara (3):
selftests: cachestat: properly link in librt
selftests: cachestat: use proper syscall number macro
selftests: cachestat: test for cachestat availability
tools/testing/selftests/cachestat/Makefile | 2 +-
.../selftests/cachestat/test_cachestat.c | 29 +++++++++++++++----
2 files changed, 25 insertions(+), 6 deletions(-)
--
2.25.1
Regressions that cause a device to no longer be probed by a driver can
have a big impact on the platform's functionality, and despite being
relatively common there isn't currently any generic test to detect them.
As an example, bootrr [1] does test for device probe, but it requires
defining the expected probed devices for each platform.
Given that the Devicetree already provides a static description of
devices on the system, it is a good basis for building such a test on
top.
This series introduces a test to catch regressions that prevent devices
from probing.
Patch 1 introduces a script to parse the kernel source using Coccinelle
and extract all compatibles that can be matched by a Devicetree node to
a driver. Patch 2 adds a kselftest that walks over the Devicetree nodes
on the current platform and compares the compatibles to the ones on the
list, and on an ignore list, to point out devices that failed to be
probed.
A compatible list is needed because not all compatibles that can show up
in a Devicetree node can be used to match to a driver, for example the
code for that compatible might use "OF_DECLARE" type macros and avoid
the driver framework, or the node might be controlled by a driver that
was bound to a different node.
An ignore list is needed for the few cases where it's common for a
driver to match a device but not probe, like for the "simple-mfd"
compatible, where the driver only probes if that compatible is the
node's first compatible.
Even though there's already scripts/dtc/dt-extract-compatibles that does
a similar job, it didn't seem to find all compatibles, returning ~3k,
while Coccinelle found ~11k. Besides that, Coccinelle actually parses
the C files, so it should be a more robust solution than relying on
regexes.
The reason for parsing the kernel source instead of relying on
information exposed by the kernel at runtime (say, looking at modaliases
or introducing some other mechanism), is to be able to catch issues
where a config was renamed or a driver moved across configs, and the
.config used by the kernel not updated accordingly. We need to parse the
source to find all compatibles present in the kernel independent of the
current config being run.
Feedback is very much welcome.
Thanks,
Nícolas
[1] https://github.com/kernelci/bootrr
Nícolas F. R. A. Prado (2):
scripts/dtc: Add script to extract matchable DT compatibles
kselftest: Add Devicetree unprobed devices test
scripts/dtc/extract-matchable-dt-compatibles | 33 +++++++++++
scripts/dtc/matchable_dt_compatibles.cocci | 58 +++++++++++++++++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/dt/.gitignore | 1 +
tools/testing/selftests/dt/Makefile | 17 ++++++
.../selftests/dt/compatible_ignore_list | 3 +
.../selftests/dt/test_unprobed_devices.sh | 58 +++++++++++++++++++
7 files changed, 171 insertions(+)
create mode 100755 scripts/dtc/extract-matchable-dt-compatibles
create mode 100644 scripts/dtc/matchable_dt_compatibles.cocci
create mode 100644 tools/testing/selftests/dt/.gitignore
create mode 100644 tools/testing/selftests/dt/Makefile
create mode 100644 tools/testing/selftests/dt/compatible_ignore_list
create mode 100755 tools/testing/selftests/dt/test_unprobed_devices.sh
--
2.41.0
When naively running all kselftests on some systems, it was observed
that the landlock selftest is quite picky and reports failures, even
though the system is fine.
Those two patches relax some tests to make them pass on older kernels:
- The landlock ABI version is only "3" in recent kernels, so patch 1/2
relaxes the test to accept other numbers.
- Older kernels or some defconfig based kernels might not implement
the landlock syscall at all. Patch 2/2 catches this.
I couldn't find an easy way to not check for the syscall availability in
*every* test in base_test.c, short of not using TEST_HARNESS_MAIN at all.
If someone has a better idea, I am all ears, especially as this approach
will get quite annoying in fs_base.c.
Cheers,
Andre
Andre Przywara (2):
selftests: landlock: allow other ABI versions
selftests: landlock: skip all tests without landlock syscall
tools/testing/selftests/landlock/base_test.c | 29 +++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
--
2.25.1