> From: Peter Xu > Sent: Friday, February 5, 2021 11:31 PM > > > > > > > > > >> or virtio-iommu > > >> since dev-iotlb (or PCIe ATS) > > > > > > > > > We may need to add this in the future. > > added Jean-Philippe in CC > > So that's the part I'm unsure about.. Since everybody is cced so maybe good > time to ask. :) > > The thing is I'm still not clear on whether dev-iotlb is useful for a full > emulation environment and how that should differ from a normal iotlb, since > after all normal iotlb will be attached with device information too.
dev-iotlb is useful in two manners. First, it's a functional prerequisite for supporting I/O page faults. Second, it has performance benefit as you don't need to contend the lock of global iotlb. > > For real hardwares, they make sense because they ask for two things: iotlb is > for IOMMU, but dev-iotlb is for the device cache. For emulation > environment > (virtio-iommu is the case) do we really need that complexity? > > Note that even if there're assigned devices under virtio-iommu in the future, > we can still isolate that and iiuc we can easily convert an iotlb (from > virtio-iommu) into a hardware IOMMU dev-iotlb no matter what type of > IOMMU is > underneath the vIOMMU. > Didn't get this point. Hardware dev-iotlb is updated by hardware (between the device and the IOMMU). How could software convert a virtual iotlb entry into hardware dev-iotlb? Thanks Kevin