On 26/09/2018 00:33, Lu Baolu wrote: > Hi Joerg, > > On 09/25/2018 09:26 PM, Joerg Roedel wrote: >> On Tue, Sep 25, 2018 at 11:15:40AM +0800, Lu Baolu wrote: >>> This might be problematic for vt-d (and other possible arch's which use >>> PASID other than SVA). When vt-d iommu works in scalable mode, a PASID >>> might be allocated for: >>> >>> (1) SVA >>> (2) Device Assignable Interface (might be a mdev or directly managed >>> within a device driver). >>> (3) SVA in VM guest >>> (4) Device Assignable Interface in VM guest >>> >>> So we can't expect that an io_mm pointer was associated with each PASID. >>> And this code might run into problem if the pasid is allocated for >>> usages other than SVA. >> >> So all of these use-cases above should work in parallel on the same >> device, just with different PASIDs? > > No. It's not required. > >> Or is a device always using only one >> of the above modes at the same time? > > A device might use one or multiple modes described above at the same > time. Yes, at the moment it's difficult to guess what device drivers will want, but I can imagine some driver offering SVA to userspace, while keeping a few PASIDs for themselves to map kernel memory. Or create mdev devices for virtualization while also allowing bare-metal SVA. So I think we should aim at enabling these use-cases in parallel, even if it doesn't necessarily need to be possible right now. Thanks, Jean
