Messages in this thread | | | Date | Tue, 31 May 2022 22:11:18 +0800 | Subject | Re: [PATCH 01/12] iommu/vt-d: Use iommu_get_domain_for_dev() in debugfs | From | Baolu Lu <> |
| |
On 2022/5/31 21:10, Jason Gunthorpe wrote: > On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote: > >> For case 2, it is a bit weird. I tried to add a rwsem lock to make the >> iommu_unmap() and dumping tables in debugfs exclusive. This does not >> work because debugfs may depend on the DMA of the devices to work. It >> seems that what we can do is to allow this race, but when we traverse >> the page table in debugfs, we will check the validity of the physical >> address retrieved from the page table entry. Then, the worst case is to >> print some useless information. > > Sounds horrible, don't you have locking around the IOPTEs of some > kind? How does updating them work reliably?
There's no locking around updating the IOPTEs. The basic assumption is that at any time, there's only a single thread manipulating the mappings of the range specified in iommu_map/unmap() APIs. Therefore, the race only exists when multiple ranges share some high-level IOPTEs. The IOMMU driver updates those IOPTEs using the compare-and-exchange atomic operation.
> > It is just debugfs, so maybe it is not the end of the world, but > still..
Fair enough. I think this is somewhat similar to that IOMMU hardware can traverse the page table at any time without considering when the CPUs update it. The IOMMU hardware will generate faults when it encounters failure during the traverse of page table. Similarly, perhaps debugfs could dump all-ones for an invalid IOPTE?
Best regards, baolu
| |