[PATCH v4 06/14] iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC

Introduce a new IOMMUFD_OBJ_VEVENTQ object for vIOMMU Event Queue that provides user space (VMM) another FD to read the vIOMMU Events. Allow a vIOMMU object to allocate vEVENTQs, with a condition that each vIOMMU can only have one single vEVENTQ per type. Add iommufd_veventq_alloc() with iommufd_

[PATCH v4 00/14] iommufd: Add vIOMMU infrastructure (Part-3: vEVENTQ)

As the vIOMMU infrastructure series part-3, this introduces a new vEVENTQ object. The existing FAULT object provides a nice notification pathway to the user space with a queue already, so let vEVENTQ reuse that. Mimicing the HWPT structure, add a common EVENTQ structure to support its derivatives:

[PATCH v4 03/14] iommufd/fault: Move iommufd_fault_iopf_handler() to header

The new vEVENTQ object will need a similar function for drivers to report the vIOMMU related events. Split the common part out to a smaller helper, and place it in the header so that CONFIG_IOMMUFD_DRIVER_CORE can include that in the driver.c file for drivers to use. Then keep iommufd_fault_iopf_h

[PATCH v4 02/14] iommufd/fault: Add an iommufd_fault_init() helper

The infrastructure of a fault object will be shared with a new vEVENTQ object in a following change. Add a helper for a vEVENTQ allocator to call it too. Reorder the iommufd_ctx_get and refcount_inc, to keep them symmetrical with the iommufd_fault_fops_release(). Since the new vEVENTQ doesn't nee

[PATCH v4 01/14] iommufd: Keep IOCTL list in an alphabetical order

Move VDEVICE upward to keep the order. Also run clang-format for the same coding style at line wrappings. No functional change. Signed-off-by: Nicolin Chen --- drivers/iommu/iommufd/main.c | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/iommu/iommufd/

[PATCH v4 07/14] iommufd/viommu: Add iommufd_viommu_get_vdev_id helper

This is a reverse search v.s. iommufd_viommu_find_dev, as drivers may want to convert a struct device pointer (physical) to its virtual device ID for an event injection to the user space VM. Again, this avoids exposing more core structures to the drivers, than the iommufd_viommu alone. Signed-off

[PATCH v4 11/14] iommufd/selftest: Add IOMMU_VEVENTQ_ALLOC test coverage

Trigger a vEVENT by feeding an idev ID and validating the returned output virt_id whether it equals to the value that was set to the vDEVICE. Signed-off-by: Nicolin Chen --- tools/testing/selftests/iommu/iommufd_utils.h | 65 +++ tools/testing/selftests/iommu/iommufd.c | 22

[PATCH v4 05/14] iommufd: Rename fault.c to eventq.c

Rename the file, aligning with the new eventq object. Reviewed-by: Kevin Tian Signed-off-by: Nicolin Chen --- drivers/iommu/iommufd/Makefile | 2 +- drivers/iommu/iommufd/{fault.c => eventq.c} | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename drivers/iommu/iommufd/{fault.

[PATCH v4 09/14] iommufd/selftest: Require vdev_id when attaching to a nested domain

When attaching a device to a vIOMMU-based nested domain, vdev_id must be present. Add a piece of code hard-requesting it, preparing for a vEVENTQ support in the following patch. Then, update the TEST_F. A HWPT-based nested domain will return a NULL new_viommu, thus no such a vDEVICE requirement.

[PATCH v4 04/14] iommufd: Abstract an iommufd_eventq from iommufd_fault

The fault object was designed exclusively for hwpt's IO page faults (PRI). But its queue implementation can be reused for other purposes too, such as hardware IRQ and event injections to user space. Meanwhile, a fault object holds a list of faults. So it's more accurate to call it a "fault queue".

[PATCH v4 12/14] Documentation: userspace-api: iommufd: Update FAULT and VEVENTQ

With the introduction of the new objects, update the doc to reflect that. Signed-off-by: Nicolin Chen --- Documentation/userspace-api/iommufd.rst | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/userspace-api/iommufd.rst b/Documentation/userspace-api/iommufd.r

[PATCH v4 10/14] iommufd/selftest: Add IOMMU_TEST_OP_TRIGGER_VEVENT for vEVENTQ coverage

The handler will get vDEVICE object from the given mdev and convert it to its per-vIOMMU virtual ID to mimic a real IOMMU driver. Signed-off-by: Nicolin Chen --- drivers/iommu/iommufd/iommufd_test.h | 10 ++ drivers/iommu/iommufd/selftest.c | 30 2 files

[PATCH v4 08/14] iommufd/viommu: Add iommufd_viommu_report_event helper

Similar to iommu_report_device_fault, this allows IOMMU drivers to report vIOMMU events from threaded IRQ handlers to user space hypervisors. Signed-off-by: Nicolin Chen --- include/linux/iommufd.h| 11 ++ drivers/iommu/iommufd/driver.c | 40 ++ 2

[PATCH v4 13/14] iommu/arm-smmu-v3: Introduce struct arm_smmu_vmaster

Use it to store all vSMMU-related data. The vsid (Virtual Stream ID) will be the first use case. Then, add a rw_semaphore to protect it. Also add a pair of arm_smmu_attach_prepare/commit_vmaster helpers to set or unset the master->vmaster point. Put these helpers inside the existing arm_smmu_attac

[PATCH v4 14/14] iommu/arm-smmu-v3: Report events that belong to devices attached to vIOMMU

Aside from the IOPF framework, iommufd provides an additional pathway to report hardware events, via the vEVENTQ of vIOMMU infrastructure. Define an iommu_vevent_arm_smmuv3 uAPI structure, and report stage-1 events in the threaded IRQ handler. Signed-off-by: Nicolin Chen --- drivers/iommu/arm/a

Re: [PATCH v8 01/21] cxl/mbox: Flag support for Dynamic Capacity Devices (DCD)

Ira Weiny wrote: > Per the CXL 3.1 specification software must check the Command Effects > Log (CEL) for dynamic capacity command support. > > Detect support for the DCD commands while reading the CEL, including: > > Get DC Config > Get DC Extent List > Add DC Response > R

[PATCH v13 1/5] modules: Support extended MODVERSIONS info

Adds a new format for MODVERSIONS which stores each field in a separate ELF section. This initially adds support for variable length names, but could later be used to add additional fields to MODVERSIONS in a backwards compatible way if needed. Any new fields will be ignored by old user tooling, un

[PATCH v13 2/5] modpost: Produce extended MODVERSIONS information

Generate both the existing modversions format and the new extended one when running modpost. Presence of this metadata in the final .ko is guarded by CONFIG_EXTENDED_MODVERSIONS. We no longer generate an error on long symbols in modpost if CONFIG_EXTENDED_MODVERSIONS is set, as they can now be app

[PATCH v13 0/5] Extended MODVERSIONS Support

This patch series is intended for use alongside the Implement DWARF modversions series [1] to enable RUST and MODVERSIONS at the same time. Elsewhere, we've seen a desire for long symbol name support for LTO symbol names [2], and the previous series came up [3] as a possible solution rather than h

[PATCH v13 3/5] modules: Allow extended modversions without basic MODVERSIONS

If you know that your kernel modules will only ever be loaded by a newer kernel, you can disable BASIC_MODVERSIONS to save space. This also allows easy creation of test modules to see how tooling will respond to modules that only have the new format. Signed-off-by: Matthew Maurer --- kernel/modu

[PATCH v13 4/5] Documentation/kbuild: Document storage of symbol information

Document where exported and imported symbols are kept, format options, and limitations. Signed-off-by: Matthew Maurer --- Documentation/kbuild/modules.rst | 20 1 file changed, 20 insertions(+) diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst

[PATCH v13 5/5] rust: Use gendwarfksyms + extended modversions for CONFIG_MODVERSIONS

From: Sami Tolvanen Previously, two things stopped Rust from using MODVERSIONS: 1. Rust symbols are occasionally too long to be represented in the original versions table 2. Rust types cannot be properly hashed by the existing genksyms approach because: * Looking up type definitions