-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[linux-6.6.y] iommu/dma: Fix not fully traversing iova reservations issue #280
[linux-6.6.y] iommu/dma: Fix not fully traversing iova reservations issue #280
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @leoliu-oc. Thanks for your PR. I'm waiting for a deepin-community member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
审阅意见:合入RMRR提交(编译通过) 之后再合入 |
”RMRR提交“是指 #261 吗?这边注意到该PR261已经合入完成了。还烦请再帮忙review了。谢谢。 |
zhaoxin inclusion category: other CVE: NA ----------------- For multiple devices in the same iommu group, sorted later devices (based on Bus:Dev.Func) have the RMRR. Sorted earlier device (without RMRR) initialized the iova domain causing the sorted later device goto done_unlock. Then, the sorted later device (with RMRR) cannot execute the iova_reserve_iommu_regions to reserve the RMRR in the group's iova domain, and other devices (in the same group) alloc iova in RMRR are permitted. DMA iova addresses conflict with RMRR in this case. There is a need to make sure all devices of the same group execute reserve iova. Substitute iova_reserve_iommu_regions with iova_reserve_pci_regions (reserved PCI window)and iova_reserve_iommu_regions(reserved resv-region, like RMRR and msi range). And then, goto iova_reserve_iommu_regions could avoid the problem when if (iovad->start_pfn) is true. Signed-off-by: leoliu-oc <leoliu-oc@zhaoxin.com>
060061c
to
b60376e
Compare
/retest |
@leoliu-oc: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
zhaoxin inclusion
category: other
CVE: NA
For multiple devices in the same iommu group, sorted later devices (based on Bus:Dev.Func) have the RMRR.
Sorted earlier device (without RMRR) initialized the iova domain causing the sorted later device goto done_unlock.
Then, the sorted later device (with RMRR) cannot execute the iova_reserve_iommu_regions to reserve the RMRR in the group's iova domain, and other devices (in the same group) alloc iova in RMRR are permitted.
DMA iova addresses conflict with RMRR in this case.
There is a need to make sure all devices of the same group execute reserve iova.
Substitute iova_reserve_iommu_regions with iova_reserve_pci_regions (reserved PCI window)and iova_reserve_iommu_regions(reserved resv-region, like RMRR and msi range). And then, goto iova_reserve_iommu_regions could avoid the problem when if (iovad->start_pfn) is true.