> From: Jacob Pan [mailto:jacob.jun.pan@xxxxxxxxxxxxxxx] > Sent: Saturday, September 8, 2018 5:25 AM > > > iommu-sva expects everywhere that the device has an iommu_domain, > > > it's the first thing we check on entry. Bypassing all of this would > > > call idr_alloc() directly, and wouldn't have any code in common > > > with the current iommu-sva. So it seems like you need a layer on > > > top of iommu-sva calling idr_alloc() when an IOMMU isn't present, > > > but I don't think it should be in drivers/iommu/ > > > > In this case I question if the PASID handling should be under > > drivers/iommu at all. > > > > See I can have a mix of VM context which are bound to processes (some > > few) and VM contexts which are standalone and doesn't care for a > > process address space. But for each VM context I need a distinct > > PASID for the hardware to work. I'm confused about VM context vs. process. Is VM referring to Virtual Machine or something else? If yes, I don't understand the binding part - what VM context is bound to (host?) process? > > > > I can live if we say if IOMMU is completely disabled we use a simple > > ida to allocate them, but when IOMMU is enabled I certainly need a > > way to reserve a PASID without an associated process. > > > VT-d would also have such requirement. There is a virtual command > register for allocate and free PASID for VM use. When that PASID > allocation request gets propagated to the host IOMMU driver, we need to > allocate PASID w/o mm. > VT-d is a bit different. In host side, PASID allocation always happens in Qemu's context, so those PASIDs are recorded with Qemu process, though the entries may point to guest page tables instead of host mm of Qemu. Thanks Kevin
