On 05/09/2018 04:15, Xu Zaibo wrote:

quoted

quoted

      1. While the series are finished well, VFIO-PCI device can be held
by only one process
          through binding IOCTL command without PASID (without PASID
being exposed user space).

It could, but isn't supported at the moment. In addition to adding
support in the I/O page fault code, we'd also need to update the VFIO
API. Currently a VFIO_TYPE1 domain always supports the MAP/UNMAP ioctl.
The case you describe isn't compatible with MAP/UNMAP, since the process
manages the shared address space with mmap or malloc. We'd probably need
to introduce a new VFIO IOMMU type, in which case the bind could be
performed implicitly when the process does VFIO_SET_IOMMU. Then the
process wouldn't need to send an additional BIND IOCTL.

ok. got it.  This is the legacy mode, so all the VFIO APIs are kept 
unchanged?

Yes, existing VFIO semantics are preserved

quoted

quoted

      2. While using VFIO-PCI device to support multiple processes with
SVA series, a primary
          process with multiple secondary processes must be deployed just
like DPDK(https://www.dpdk.org/).
          And, the PASID still has to be exposed to user land.

Right. A third case, also implemented by this patch (and complete), is
the primary process simply doing a BIND for itself, and using the
returned PASID to share its own address space with the device.

ok. But I am worried that the sulotion of one primary processes with 
several secondary ones

is a little bit limited. Maybe, users don't want to depend on the 
primary process. :)

I don't see a better way for vfio-pci, though. But more importantly, I
don't know of any users :) While the feature is great for testing new
hardware, and I've been using it for all kinds of stress testing, I
haven't received feedback from possible users in production settings
(DPDK etc) and can't speculate about what they'd prefer.

Thanks,
Jean