backport iommu关于default_domain的改动#82
Conversation
sterling-teng
force-pushed
the
rvck-6.6
branch
2 times, most recently
from
7a1bcfc to
b221452
Compare
|
iommu的其中一部分前置补丁，已经重新rebase，麻烦尽快merge一下 |
好的，预计要到本周晚些时候。 |
|
/check |
|
开始测试 |
|
check patch done. log: https://jenkins.oerv.ac.cn/job/rvck-pipeline/job/check-patch/118/consoleFull |
|
Kernel build success! |
|
kunit test done. log:https://jenkins.oerv.ac.cn/job/rvck-pipeline/job/kunit-test/124/consoleFull |
|
Lava check fail! log: https://jenkins.oerv.ac.cn/job/rvck-pipeline/job/rvck-lava-trigger/148/consoleFull, result url: https://lava.oerv.ac.cn/results/442/0_rvck_common-test_qemu |
mainline inclusion from mainline-v6.14-rc7 commit b46064a category: feature bugzilla: RVCK-Project#75 -------------------------------- It turns out that deferred default domain creation leaves a subtle race window during iommu_device_register() wherein a client driver may asynchronously probe in parallel and get as far as performing DMA API operations with dma-direct, only to be switched to iommu-dma underfoot once the default domain attachment finally happens, with obviously disastrous consequences. Even the wonky of_iommu_configure() path is at risk, since iommu_fwspec_init() will no longer defer client probe as the instance ops are (necessarily) already registered, and the "replay" iommu_probe_device() call can see dev->iommu_group already set and so think there's nothing to do either. Fortunately we already have the right tool in the right place in the form of iommu_device_use_default_domain(), which just needs to ensure that said default domain is actually ready to *be* used. Deferring the client probe shouldn't have too much impact, given that this only happens while the IOMMU driver is probing, and thus due to kick the deferred probe list again once it finishes. Reported-by: Charan Teja Kalla <quic_charante@quicinc.com> Fixes: 98ac73f ("iommu: Require a default_domain for all iommu drivers") Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/e88b94c9b575034a2c98a48b3d383654cbda7902.1740753261.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
|
开始测试 |
|
check patch done. log: https://jenkins.oerv.ac.cn/job/rvck-pipeline/job/check-patch/141/consoleFull |
|
Kernel build success! |
|
kunit test done. log:https://jenkins.oerv.ac.cn/job/rvck-pipeline/job/kunit-test/148/consoleFull |
|
Lava check done! result url: https://lava.oerv.ac.cn/results/528/0_rvck_common-test_qemu |
4 participants
参见如下riscv iommu的合入计划，首先backport iommu关于default_domain的改动，该特性已经测试通过。
#73
这个特性在RVCK重新合入iommu功能，这个PR为RISC-V IOMMU的其中一个前置补丁，它增加了Identity Domain，并为所有的iommu提供一个default domain，主要测试方法为检查各个架构的iommu是否能正常初始化并生成default_domain。。
这个补丁的核心目的是重构IOMMU子系统默认域类型的处理方式，主要修改点如下：
1、移除 set_platform_dma_ops回调引入 identity_domain，iommu会尝试创建一个能满足设备要求和驱动能力的默认域（主要是DMA域）。如果设备需要标识映射且驱动支持，则创建标识域；如果设备需要DMA映射且驱动支持，则创建DMA域。
2、所有实现了 default_domain 的IOMMU驱动（如Intel VT-d, AMD-Vi, ARM SMMU-v1/v2, etc.）都需要进行修改以适应新的接口。