On Sun, Sep 19, 2021 at 02:38:33PM +0800, Liu Yi L wrote: > This patch exposes the device-centric interface for vfio-pci devices. To > be compatiable with existing users, vfio-pci exposes both legacy group > interface and device-centric interface. > > As explained in last patch, this change doesn't apply to devices which > cannot be forced to snoop cache by their upstream iommu. Such devices > are still expected to be opened via the legacy group interface. > > When the device is opened via /dev/vfio/devices, vfio-pci should prevent > the user from accessing the assigned device because the device is still > attached to the default domain which may allow user-initiated DMAs to > touch arbitrary place. The user access must be blocked until the device > is later bound to an iommufd (see patch 08). The binding acts as the > contract for putting the device in a security context which ensures user- > initiated DMAs via this device cannot harm the rest of the system. > > This patch introduces a vdev->block_access flag for this purpose. It's set > when the device is opened via /dev/vfio/devices and cleared after binding > to iommufd succeeds. mmap and r/w handlers check this flag to decide whether > user access should be blocked or not. This should not be in vfio_pci. AFAIK there is no condition where a vfio driver can work without being connected to some kind of iommu back end, so the core code should handle this interlock globally. A vfio driver's ops should not be callable until the iommu is connected. The only vfio_pci patch in this series should be adding a new callback op to take in an iommufd and register the pci_device as a iommufd device. Jason
