From: Jacob Pan [mailto:jacob.jun.pan at linux.intel.com]
Sent: Saturday, September 8, 2018 5:25 AM

quoted

quoted

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?

quoted

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