928a49644f
without Giant held. A quick outline of the locking strategy: Since all IOMMUs are synchronized, there is a single lock, iommu_mtx, which protects the hardware registers (where needed) and the global and per-IOMMU software states. As soon as the IOMMUs are divorced, each struct iommu_state will have its own mutex (and the remaining global state will be moved into the struct). The dvma rman has its own internal mutex; the TSB slots may only be accessed by the owner of the corresponding resource, so neither needs extra protection. Since there is a second access path to maps via LRU queues, the consumer- provided locking is not sufficient; therefore, each map which is on a queue is additionally protected by iommu_mtx (in part, there is one member which only the map owner may access). Each map on a queue may be accessed and removed from or repositioned in a queue in any context as long as the lock is held; only the owner may insert a map. To reduce lock contention, some bus_dma functions remove the map from the queue temporarily (on behalf of the map owner) for some operations and reinsert it when they are done. Shorter operations and operations which are not done on behalf of the lock owner are completely covered by the lock. To facilitate the locking, reorganize the streaming buffer handling; while being there, fix an old oversight which would cause the streaming buffer to always be flushed, regardless of whether streaming was enabled in the TSB entry. The streaming buffer is still disabled for now, since there are a number of drivers which lack critical bus_dmamp_sync() calls. Additional testing by: jake |
||
---|---|---|
.. | ||
central | ||
compile | ||
conf | ||
ebus | ||
fhc | ||
include | ||
isa | ||
pci | ||
sbus | ||
sparc64 |