Conversation
mainline inclusion from mainline-v6.7-rc1 commit b18f729 category: feature bugzilla: RVCK-Project#86 -------------------------------- For the sake of coherency, use local labels in assembly when applicable. This also avoid kprobes being confused when applying a kprobe since the size of function is computed by checking where the next visible symbol is located. This might end up in computing some function size to be way shorter than expected and thus failing to apply kprobes to the specified offset. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20231024132655.730417-2-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7-rc1 commit 76329c6 category: feature bugzilla: RVCK-Project#86 -------------------------------- ENTRY()/END()/WEAK() macros are deprecated and we should make use of the new SYM_*() macros [1] for better annotation of symbols. Replace the deprecated ones with the new ones and fix wrong usage of END()/ENDPROC() to correctly describe the symbols. [1] https://docs.kernel.org/core-api/asm-annotations.html Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20231024132655.730417-3-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7-rc1 commit 4cc0d8a category: feature bugzilla: RVCK-Project#86 -------------------------------- Some data were incorrectly annotated with SYM_FUNC_*() instead of SYM_DATA_*() ones. Use the correct ones. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20231024132655.730417-4-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7 commit ecd2ada category: feature bugzilla: RVCK-Project#86 -------------------------------- Add kernel_vector_begin() and kernel_vector_end() function declarations and corresponding definitions in kernel_mode_vector.c These are needed to wrap uses of vector in kernel mode. Co-developed-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Greentime Hu <greentime.hu@sifive.com> Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Eric Biggers <ebiggers@google.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20240115055929.4736-2-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7 commit 956895b category: feature bugzilla: RVCK-Project#86 -------------------------------- The goal of this patch is to provide full support of Vector in kernel softirq context. So that some of the crypto alogrithms won't need scalar fallbacks. By disabling bottom halves in active kernel-mode Vector, softirq will not be able to nest on top of any kernel-mode Vector. So, softirq context is able to use Vector whenever it runs. After this patch, Vector context cannot start with irqs disabled. Otherwise local_bh_enable() may run in a wrong context. Disabling bh is not enough for RT-kernel to prevent preeemption. So we must disable preemption, which also implies disabling bh on RT. Related-to: commit 696207d ("arm64/sve: Make kernel FPU protection RT friendly") Related-to: commit 66c3ec5 ("arm64: neon: Forbid when irqs are disabled") Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Eric Biggers <ebiggers@google.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20240115055929.4736-3-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7 commit c5674d0 category: feature bugzilla: RVCK-Project#86 -------------------------------- This patch adds support for vector optimized XOR and it is tested in qemu. Co-developed-by: Han-Kuan Chen <hankuan.chen@sifive.com> Signed-off-by: Han-Kuan Chen <hankuan.chen@sifive.com> Signed-off-by: Greentime Hu <greentime.hu@sifive.com> Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20240115055929.4736-4-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7 commit 7df56cb category: feature bugzilla: RVCK-Project#86 -------------------------------- User will use its Vector registers only after the kernel really returns to the userspace. So we can delay restoring Vector registers as long as we are still running in kernel mode. So, add a thread flag to indicates the need of restoring Vector and do the restore at the last arch-specific exit-to-user hook. This save the context restoring cost when we switch over multiple processes that run V in kernel mode. For example, if the kernel performs a context swicth from A->B->C, and returns to C's userspace, then there is no need to restore B's V-register. Besides, this also prevents us from repeatedly restoring V context when executing kernel-mode Vector multiple times. The cost of this is that we must disable preemption and mark vector as busy during vstate_{save,restore}. Because then the V context will not get restored back immediately when a trap-causing context switch happens in the middle of vstate_{save,restore}. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20240115055929.4736-5-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7 commit c2a658d category: feature bugzilla: RVCK-Project#86 -------------------------------- This patch utilizes Vector to perform copy_to_user/copy_from_user. If Vector is available and the size of copy is large enough for Vector to perform better than scalar, then direct the kernel to do Vector copies for userspace. Though the best programming practice for users is to reduce the copy, this provides a faster variant when copies are inevitable. The optimal size for using Vector, copy_to_user_thres, is only a heuristic for now. We can add DT parsing if people feel the need of customizing it. The exception fixup code of the __asm_vector_usercopy must fallback to the scalar one because accessing user pages might fault, and must be sleepable. Current kernel-mode Vector does not allow tasks to be preemptible, so we must disactivate Vector and perform a scalar fallback in such case. The original implementation of Vector operations comes from https://github.com/sifive/sifive-libc, which we agree to contribute to Linux kernel. Co-developed-by: Jerry Shih <jerry.shih@sifive.com> Signed-off-by: Jerry Shih <jerry.shih@sifive.com> Co-developed-by: Nick Knight <nick.knight@sifive.com> Signed-off-by: Nick Knight <nick.knight@sifive.com> Suggested-by: Guo Ren <guoren@kernel.org> Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20240115055929.4736-6-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7 commit a93fdaf category: feature bugzilla: RVCK-Project#86 -------------------------------- SR_SD summarizes the dirty status of FS/VS/XS. However, the current code structure does not fully utilize it because each extension specific code is divided into an individual segment. So remove the SR_SD check for now. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Song Shuai <songshuaishuai@tinylab.org> Reviewed-by: Guo Ren <guoren@kernel.org> Tested-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20240115055929.4736-7-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
…ore}() mainline inclusion from mainline-v6.7 commit d6c78f1 category: feature bugzilla: RVCK-Project#86 -------------------------------- riscv_v_vstate_{save,restore}() can operate only on the knowlege of struct __riscv_v_ext_state, and struct pt_regs. Let the caller decides which should be passed into the function. Meanwhile, the kernel-mode Vector is going to introduce another vstate, so this also makes functions potentially able to be reused. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20240115055929.4736-8-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7 commit 5b6048f category: feature bugzilla: RVCK-Project#86 -------------------------------- riscv_v_ctrl_set() should only touch bits within PR_RISCV_V_VSTATE_CTRL_MASK. So, use the mask when we really set task's vstate_ctrl. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20240115055929.4736-9-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7 commit bd446f5 category: feature bugzilla: RVCK-Project#86 -------------------------------- The allocation size of thread.vstate.datap is always riscv_v_vsize. So it is possbile to use kmem_cache_* to manage the allocation. This gives users more information regarding allocation of vector context via /proc/slabinfo. And it potentially reduces the latency of the first-use trap because of the allocation caches. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20240115055929.4736-10-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7 commit 2080ff9 category: feature bugzilla: RVCK-Project#86 -------------------------------- Add kernel_vstate to keep track of kernel-mode Vector registers when trap introduced context switch happens. Also, provide riscv_v_flags to let context save/restore routine track context status. Context tracking happens whenever the core starts its in-kernel Vector executions. An active (dirty) kernel task's V contexts will be saved to memory whenever a trap-introduced context switch happens. Or, when a softirq, which happens to nest on top of it, uses Vector. Context retoring happens when the execution transfer back to the original Kernel context where it first enable preempt_v. Also, provide a config CONFIG_RISCV_ISA_V_PREEMPTIVE to give users an option to disable preemptible kernel-mode Vector at build time. Users with constraint memory may want to disable this config as preemptible kernel-mode Vector needs extra space for tracking of per thread's kernel-mode V context. Or, users might as well want to disable it if all kernel-mode Vector code is time sensitive and cannot tolerate context switch overhead. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20240115055929.4736-11-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.7 commit c27fa53 category: feature bugzilla: RVCK-Project#86 -------------------------------- The RISC-V Vector specification states in "Appendix D: Calling Convention for Vector State" [1] that "Executing a system call causes all caller-saved vector registers (v0-v31, vl, vtype) and vstart to become unspecified.". In the RISC-V kernel this is called "discarding the vstate". Returning from a signal handler via the rt_sigreturn() syscall, vector discard is also performed. However, this is not an issue since the vector state should be restored from the sigcontext, and therefore not care about the vector discard. The "live state" is the actual vector register in the running context, and the "vstate" is the vector state of the task. A dirty live state, means that the vstate and live state are not in synch. When vectorized user_from_copy() was introduced, an bug sneaked in at the restoration code, related to the discard of the live state. An example when this go wrong: 1. A userland application is executing vector code 2. The application receives a signal, and the signal handler is entered. 3. The application returns from the signal handler, using the rt_sigreturn() syscall. 4. The live vector state is discarded upon entering the rt_sigreturn(), and the live state is marked as "dirty", indicating that the live state need to be synchronized with the current vstate. 5. rt_sigreturn() restores the vstate, except the Vector registers, from the sigcontext 6. rt_sigreturn() restores the Vector registers, from the sigcontext, and now the vectorized user_from_copy() is used. The dirty live state from the discard is saved to the vstate, making the vstate corrupt. 7. rt_sigreturn() returns to the application, which crashes due to corrupted vstate. Note that the vectorized user_from_copy() is invoked depending on the value of CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. Default is 768, which means that vlen has to be larger than 128b for this bug to trigger. The fix is simply to mark the live state as non-dirty/clean prior performing the vstate restore. Link: https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-8abdb41-2024-03-26/unpriv-isa-asciidoc.pdf # [1] Reported-by: Charlie Jenkins <charlie@rivosinc.com> Reported-by: Vineet Gupta <vgupta@kernel.org> Fixes: c2a658d ("riscv: lib: vectorize copy_to_user/copy_from_user") Signed-off-by: Björn Töpel <bjorn@rivosinc.com> Reviewed-by: Andy Chiu <andy.chiu@sifive.com> Tested-by: Vineet Gupta <vineetg@rivosinc.com> Link: https://lore.kernel.org/r/20240403072638.567446-1-bjorn@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 category: feature bugzilla: RVCK-Project#75 -------------------------------- There are issues with this patch's integration, as it does not align with the Linux community patch. We will re-apply it after integrating default_domain feature later. Fixes: a6dbcf6 (iommu: Handle race with default domain setup) Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit df31b29 category: feature bugzilla: RVCK-Project#75 -------------------------------- This allows a driver to set a global static to an IDENTITY domain and the core code will automatically use it whenever an IDENTITY domain is requested. By making it always available it means the IDENTITY can be used in error handling paths to force the iommu driver into a known state. Devices implementing global static identity domains should avoid failing their attach_dev ops. To make global static domains simpler allow drivers to omit their free function and update the iommufd selftest. Convert rockchip to use the new mechanism. Tested-by: Steven Price <steven.price@arm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/1-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit 1c68cbc category: feature bugzilla: RVCK-Project/rvck-olk#75 -------------------------------- This is used when the iommu driver is taking control of the dma_ops, currently only on S390 and power spapr. It is designed to preserve the original ops->detach_dev() semantic that these S390 was built around. Provide an opaque domain type and a 'default_domain' ops value that allows the driver to trivially force any single domain as the default domain. Update iommufd selftest to use this instead of set_platform_dma_ops Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/2-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit e04c748 category: feature bugzilla: RVCK-Project/rvck-olk#75 -------------------------------- The PLATFORM domain will be set as the default domain and attached as normal during probe. The driver will ignore the initial attach from a NULL domain to the PLATFORM domain. After this, the PLATFORM domain's attach_dev will be called whenever we detach from an UNMANAGED domain (eg for VFIO). This is the same time the original design would have called op->detach_dev(). This is temporary until the S390 dma-iommu.c conversion is merged. Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/4-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit 8565915 category: feature bugzilla: RVCK-Project#75 -------------------------------- This driver is nonsensical. To not block migrating the core API away from NULL default_domains give it a hacky of a PLATFORM domain that keeps it working exactly as it always did. Leave some comments around to warn away any future people looking at this. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/5-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit 90057dc category: feature bugzilla: RVCK-Project#75 -------------------------------- What mtk does during mtk_iommu_v1_set_platform_dma() is actually putting the iommu into identity mode. Make this available as a proper IDENTITY domain. The mtk_iommu_v1_def_domain_type() from commit 8bbe13f ("iommu/mediatek-v1: Add def_domain_type") explains this was needed to allow probe_finalize() to be called, but now the IDENTITY domain will do the same job so change the returned def_domain_type. mkt_v1 is the only driver that returns IOMMU_DOMAIN_UNMANAGED from def_domain_type(). This allows the next patch to enforce an IDENTITY domain policy for this driver. Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/7-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
…in_type() mainline inclusion from mainline-v6.6-rc3 commit 59ddce4 category: feature bugzilla: RVCK-Project#75 -------------------------------- Except for dart (which forces IOMMU_DOMAIN_DMA) every driver returns 0 or IDENTITY from ops->def_domain_type(). The drivers that return IDENTITY have some kind of good reason, typically that quirky hardware really can't support anything other than IDENTITY. Arrange things so that if the driver says it needs IDENTITY then iommu_get_default_domain_type() either fails or returns IDENTITY. It will not ignore the driver's override to IDENTITY. Split the function into two steps, reducing the group device list to the driver's def_domain_type() and the untrusted flag. Then compute the result based on those two reduced variables. Fully reject combining untrusted with IDENTITY. Remove the debugging print on the iommu_group_store_type() failure path, userspace should not be able to trigger kernel prints. This makes the next patch cleaner that wants to force IDENTITY always for ARM_IOMMU because there is no support for DMA. Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/8-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit e98befd category: feature bugzilla: RVCK-Project#75 -------------------------------- Even though dma-iommu.c and CONFIG_ARM_DMA_USE_IOMMU do approximately the same stuff, the way they relate to the IOMMU core is quiet different. dma-iommu.c expects the core code to setup an UNMANAGED domain (of type IOMMU_DOMAIN_DMA) and then configures itself to use that domain. This becomes the default_domain for the group. ARM_DMA_USE_IOMMU does not use the default_domain, instead it directly allocates an UNMANAGED domain and operates it just like an external driver. In this case group->default_domain is NULL. If the driver provides a global static identity_domain then automatically use it as the default_domain when in ARM_DMA_USE_IOMMU mode. This allows drivers that implemented default_domain == NULL as an IDENTITY translation to trivially get a properly labeled non-NULL default_domain on ARM32 configs. With this arrangment when ARM_DMA_USE_IOMMU wants to disconnect from the device the normal detach_domain flow will restore the IDENTITY domain as the default domain. Overall this makes attach_dev() of the IDENTITY domain called in the same places as detach_dev(). This effectively migrates these drivers to default_domain mode. For drivers that support ARM64 they will gain support for the IDENTITY translation mode for the dma_api and behave in a uniform way. Drivers use this by setting ops->identity_domain to a static singleton iommu_domain that implements the identity attach. If the core detects ARM_DMA_USE_IOMMU mode then it automatically attaches the IDENTITY domain during probe. Drivers can continue to prevent the use of DMA translation by returning IOMMU_DOMAIN_IDENTITY from def_domain_type, this will completely prevent IOMMU_DMA from running but will not impact ARM_DMA_USE_IOMMU. This allows removing the set_platform_dma_ops() from every remaining driver. Remove the set_platform_dma_ops from rockchip and mkt_v1 as all it does is set an existing global static identity domain. mkt_v1 does not support IOMMU_DOMAIN_DMA and it does not compile on ARM64 so this transformation is safe. Tested-by: Steven Price <steven.price@arm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/9-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit b3d1496 category: feature bugzilla: RVCK-Project#75 -------------------------------- What exynos calls exynos_iommu_detach_device is actually putting the iommu into identity mode. Move to the new core support for ARM_DMA_USE_IOMMU by defining ops->identity_domain. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/10-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit c8cc265 category: feature bugzilla: RVCK-Project#75 -------------------------------- What tegra-smmu does during tegra_smmu_set_platform_dma() is actually putting the iommu into identity mode. Move to the new core support for ARM_DMA_USE_IOMMU by defining ops->identity_domain. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/11-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit f128094 category: feature bugzilla: RVCK-Project#75 -------------------------------- All ARM64 iommu drivers should support IOMMU_DOMAIN_DMA to enable dma-iommu.c. tegra is blocking dma-iommu usage, and also default_domain's, because it wants an identity translation. This is needed for some device quirk. The correct way to do this is to support IDENTITY domains and use ops->def_domain_type() to return IOMMU_DOMAIN_IDENTITY for only the quirky devices. Add support for IOMMU_DOMAIN_DMA and force IOMMU_DOMAIN_IDENTITY mode for everything so no behavior changes. Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/12-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit bbe39b7 category: feature bugzilla: RVCK-Project#75 -------------------------------- What omap does during omap_iommu_set_platform_dma() is actually putting the iommu into identity mode. Move to the new core support for ARM_DMA_USE_IOMMU by defining ops->identity_domain. This driver does not support IOMMU_DOMAIN_DMA, however it cannot be compiled on ARM64 either. Most likely it is fine to support dma-iommu.c Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/13-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit 78fc30b category: feature bugzilla: RVCK-Project#75 -------------------------------- What msm does during msm_iommu_set_platform_dma() is actually putting the iommu into identity mode. Move to the new core support for ARM_DMA_USE_IOMMU by defining ops->identity_domain. This driver does not support IOMMU_DOMAIN_DMA, however it cannot be compiled on ARM64 either. Most likely it is fine to support dma-iommu.c Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/14-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit 24b1d47 category: feature bugzilla: RVCK-Project#75 -------------------------------- All drivers are now using IDENTITY or PLATFORM domains for what this did, we can remove it now. It is no longer possible to attach to a NULL domain. Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Niklas Schnelle <schnelle@linux.ibm.com> Tested-by: Steven Price <steven.price@arm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/15-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit 786478a category: feature bugzilla: RVCK-Project#75 -------------------------------- This brings back the ops->detach_dev() code that commit 1b932ce ("iommu: Remove detach_dev callbacks") deleted and turns it into an IDENTITY domain. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/16-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
mainline inclusion from mainline-v6.6-rc3 commit 666c9f1 category: feature bugzilla: RVCK-Project#75 -------------------------------- This brings back the ops->detach_dev() code that commit 1b932ce ("iommu: Remove detach_dev callbacks") deleted and turns it into an IDENTITY domain. Also reverts commit 584d334 ("iommu/ipmmu-vmsa: Remove ipmmu_utlb_disable()") Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/17-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
|
开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17355495866 参数解析结果
|
|
修复update-status 无法拼接结果问题 |
|
开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17356778823 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3/ LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/580 lava result count: call: 1 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17358042355 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3/ LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/584 lava result count: call: 1 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17372452319 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3/ LAVA Checkargs:
result:Lava check fail! lava log: https://lava.oerv.ac.cn/scheduler/job/599 lava result count: call: 1 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17384407378 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3/ LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/604 lava result count: [fail]: 174, [pass]: 1434, [skip]: 291 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17391209460 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3/ LAVA Checkargs:
result:Lava check fail! lava log: https://lava.oerv.ac.cn/scheduler/job/606 lava result count: call: 1 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17428977172 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3/ LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/630 lava result count: [fail]: 174, [pass]: 1434, [skip]: 291 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17438043407 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3/ LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/642 lava result count: [fail]: 174, [pass]: 1434, [skip]: 291 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17456771216 参数解析结果
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17457471101 参数解析结果
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17489587396 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3/ LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/655 lava result count: [fail]: 174, [pass]: 1434, [skip]: 291 Check Patch Result
|
|
/check 新增了commentid区分单次评论触发的检查 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17509611879 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3/ LAVA Checkargs:
result:Lava check fail! lava log: https://lava.oerv.ac.cn/scheduler/job/661 lava result count: call: 1 Check Patch Result
|
|
/check 新增了commentid区分单次评论触发的检查 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17510332781 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3_3260810152/ LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/662 lava result count: [fail]: 176, [pass]: 1432, [skip]: 291 Check Patch Result
|
|
/check 新增了 md5sum 值传递 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17511269892 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3_3261366474/ LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/663 lava result count: [fail]: 175, [pass]: 1433, [skip]: 291 Check Patch Result
|
|
/check |
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17524001401 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3_3263469955/ c8db575c24a9838cec4149191671c44f /srv/guix_result/ceb2003a1c6c130c73d3c4f1f807a9ed19eed1e0/Image LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/665 lava result count: [fail]: 175, [pass]: 1433, [skip]: 291 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17529218771 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3_3263779974/ a376287939c7eadf70711ee181b21b37 /srv/guix_result/ceb2003a1c6c130c73d3c4f1f807a9ed19eed1e0/Image LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/669 lava result count: [fail]: 175, [pass]: 1433, [skip]: 291 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17530443881 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Check Patch Result
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3_3263850268/ 0a155c4c66bd45488776c0f32d5f39f4 /srv/guix_result/ceb2003a1c6c130c73d3c4f1f807a9ed19eed1e0/Image LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/673 lava result count: [fail]: 174, [pass]: 1434, [skip]: 291 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17539190003 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3_3264497206/ 7ffe17f119e2128e1e9fb0d9b54a8d13 /srv/guix_result/ceb2003a1c6c130c73d3c4f1f807a9ed19eed1e0/Image LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/677 lava result count: call: 1 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17549450869 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3_3265884373/ bb06fe4a6b393e5c88a7f0a2fb2b61b6 /srv/guix_result/ceb2003a1c6c130c73d3c4f1f807a9ed19eed1e0/Image LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/681 lava result count: [fail]: 175, [pass]: 1433, [skip]: 291 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17574483982 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3_3269159732/ ebbfc0d8b85f01750d97a9bae6f26458 /srv/guix_result/ceb2003a1c6c130c73d3c4f1f807a9ed19eed1e0/Image LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/683 lava result count: [fail]: 174, [pass]: 1434, [skip]: 291 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17612569156 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3_3274567395/ da37d0416e8f3fd0aa792f84592d6b71 /srv/guix_result/ceb2003a1c6c130c73d3c4f1f807a9ed19eed1e0/Image LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/699 lava result count: [fail]: 174, [pass]: 1434, [skip]: 291 Check Patch Result
|
|
/check 开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/17668619677 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3_3284224235/ fb2fc9ba9b655525874a6570a9122ec8 /srv/guix_result/ceb2003a1c6c130c73d3c4f1f807a9ed19eed1e0/Image LAVA Checkargs:
result:Lava check done! lava log: https://lava.oerv.ac.cn/scheduler/job/733 lava result count: [fail]: 175, [pass]: 1433, [skip]: 291 Check Patch Result
|
|
开始测试 log: https://github.com/OERV-RVCI/rvck/actions/runs/24279552667 参数解析结果
测试完成 详细结果:RVCK result
Kunit Test Resultkunit test failed detail log: https://github.com/OERV-RVCI/rvck/actions/runs/24279552667/attempts/1/summary-70899176062Kernel Build ResultKernel build succeeded: OERV-RVCI/rvck/3__1/ 280f70cc6999eef6a25328c674fa0892 /srv/guix_result/ceb2003a1c6c130c73d3c4f1f807a9ed19eed1e0/Image detail log: https://github.com/OERV-RVCI/rvck/actions/runs/24279552667/attempts/1/summary-70899176084LAVA Check
result: Lava check done!
detail log: https://github.com/OERV-RVCI/rvck/actions/runs/24279552667/attempts/1/summary-70906191452Check Patch Result
detail log: https://github.com/OERV-RVCI/rvck/actions/runs/24279552667/attempts/1/summary-70899176056 |
No description provided.