On Fri, Jan 14, 2022 at 01:58:07PM +0800, Jason Wang wrote: > > > Right, but I think you meant to do this only when scalable mode is > > > disabled. > > > > Yes IMHO it will definitely suite for !scalable case since that's exactly > > what > > we did before. What I'm also wondering is even if scalable is enabled but > > no > > "real" pasid is used, so if all the translations go through the default > > pasid > > that stored in the device context entry, then maybe we can ignore checking > > it. > > The latter is the "hacky" part mentioned above. > > The problem I see is that we can't know what PASID is used as default > without reading the context entry?
Can the default NO_PASID being used in mixture of !NO_PASID use case on the same device? If that's possible, then I agree.. My previous idea should be based on the fact that if NO_PASID is used on one device, then all translations will be based on NO_PASID, but now I'm not sure of it. > > > > > The other thing to mention is, if we postpone the iotlb lookup to be after > > context entry, then logically we can have per-device iotlb, that means we > > can > > replace IntelIOMMUState.iotlb with VTDAddressSpace.iotlb in the future, too, > > which can also be more efficient. > > Right but we still need to limit the total slots and ATS is a better > way to deal with the IOTLB bottleneck actually. I think it depends on how the iotlb ghash is implemented. Logically I think if we can split the cache to per-device it'll be slightly better because we don't need to iterate over iotlbs of other devices when lookup anymore; meanwhile each iotlb takes less space too (no devfn needed anymore). Thanks, -- Peter Xu