> From: Eric Auger <eric.auger@xxxxxxxxxx> > Sent: Tuesday, August 10, 2021 3:17 PM > > Hi Kevin, > > On 8/5/21 2:36 AM, Tian, Kevin wrote: > >> From: Eric Auger <eric.auger@xxxxxxxxxx> > >> Sent: Wednesday, August 4, 2021 11:59 PM > >> > > [...] > >>> 1.2. Attach Device to I/O address space > >>> +++++++++++++++++++++++++++++++++++++++ > >>> > >>> Device attach/bind is initiated through passthrough framework uAPI. > >>> > >>> Device attaching is allowed only after a device is successfully bound to > >>> the IOMMU fd. User should provide a device cookie when binding the > >>> device through VFIO uAPI. This cookie is used when the user queries > >>> device capability/format, issues per-device iotlb invalidation and > >>> receives per-device I/O page fault data via IOMMU fd. > >>> > >>> Successful binding puts the device into a security context which isolates > >>> its DMA from the rest system. VFIO should not allow user to access the > >> s/from the rest system/from the rest of the system > >>> device before binding is completed. Similarly, VFIO should prevent the > >>> user from unbinding the device before user access is withdrawn. > >> With Intel scalable IOV, I understand you could assign an RID/PASID to > >> one VM and another one to another VM (which is not the case for ARM). > Is > >> it a targetted use case?How would it be handled? Is it related to the > >> sub-groups evoked hereafter? > > Not related to sub-group. Each mdev is bound to the IOMMU fd > respectively > > with the defPASID which represents the mdev. > But how does it work in term of security. The device (RID) is bound to > an IOMMU fd. But then each SID/PASID may be working for a different VM. > How do you detect this is safe as each SID can work safely for a > different VM versus the ARM case where it is not possible. PASID is managed by the parent driver, which knows which PASID to be used given a mdev when later attaching it to an IOASID. > > 1.3 says > " > > 1) A successful binding call for the first device in the group creates > the security context for the entire group, by: > " > What does it mean for above scalable IOV use case? > This is a good question (as Alex raised) which needs more explanation in next version: https://lore.kernel.org/linux-iommu/20210712124150.2bf421d1.alex.williamson@xxxxxxxxxx/ In general we need provide different helpers for binding pdev/mdev/ sw mdev. 1.3 in v2 describes the behavior for pdev via iommu_register_ device(). for mdev a new helper (e.g. iommu_register_device_pasid()) is required and then the IOMMU-API will also provide a pasid variation for creating security context per pasid. sw mdev will also have its binding helper to indicate no routing info required in ioasid attaching. Thanks Kevin
