Re: [PATCH v2 13/40] vfio: Add support for Shared Virtual Addressing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 2018/9/4 18:57, Jean-Philippe Brucker wrote:
On 04/09/2018 03:12, Xu Zaibo wrote:
On 2018/9/3 18:34, Jean-Philippe Brucker wrote:
On 01/09/18 03:23, Xu Zaibo wrote:
As one application takes a whole function while using VFIO-PCI, why do
the application and the
function need to enable PASID capability? (Since just one I/O page table
is enough for them.)
At the moment the series doesn't provide support for SVA without PASID
(on the I/O page fault path, 08/40). In addition the BIND ioctl could be
used by the owner application to bind other processes (slaves) and
perform sub-assignment. But that feature is incomplete because we don't
send stop_pasid notification to the owner when a slave dies.

So, Could I understand like this?

      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?
      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. :)



Thanks,
Zaibo

.







[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux