> From: Tian, Kevin > Sent: Wednesday, July 25, 2018 10:16 AM > [...] > > > > There is another way: as we're planning to add a generic pasid_alloc() > > function to the IOMMU API, the mdev module itself could allocate a > > default PASID for each mdev by calling pasid_alloc() on the mdev's > > parent, and then do map()/unmap() with that PASID. This way we don't > > have to add IOMMU ops to the mdev bus, everything can still be done > > using the ops of the parent. And IOMMU drivers "only" have to > implement > > PASID ops, which will be reused by drivers other than mdev. > > yes, PASID is more general abstraction than mdev. However there is > one problem. Please note with new scalable mode now PASID is not > used just for SVA. You can do 1st-level, 2nd-level and nested in PASID > granularity, meaning each PASID can be bound to an unique iommu > domain. However today IOMMU driver allows only one iommu_domain > per device. If we simply install allocated PASID to parent device, we > should also remove that iommu_domain limitation. Is it the way that > we want to pursue? > > mdev avoids such problem as it introduces a separate device... another thing to think about is to simplify the caller logic. It would be good to have consistent IOMMU APIs cross PCI device and mdev, for common VFIO operations e.g. map/unmap, iommu_ attach_group, etc. If we need special version ops with PASID, it brings burden to VFIO and other IOMMU clients... For IOMMU-capable mdev, there are two use cases which have been talked so far: 1) mdev with PASID-granular DMA isolation 2) mdev inheriting RID from parent device (no sharing) 1) is what this RFC is currently for. 2) is what Alex concerned which is not covered in RFC yet. In my mind, an ideal design is like below: a) VFIO provides an interface for parent driver to specify whether a mdev is IOMMU capable, with flag to indicate whether it's PASID-granular or RID-inherit; b) Once an IOMMU-capable mdev is created, VFIO treats it no different from normal physical devices, using exactly same IOMMU APIs to operate (including future SVA). VFIO doesn't care whether PASID or RID will be used in hardware; c) IOMMU driver then handle RID/PASID difference internally, based on its own configuration and mdev type. To support above goal, I feel a new device handle is a nice fit to represent mdev within IOMMU driver, with same set of capabilities as observed on its parent device. Jean, maybe I didn't fully understand your proposal. Can you elaborate whether above goal can be achieved with it? Thanks Kevin
