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

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

 




On 2018/9/5 19:02, Jean-Philippe Brucker wrote:
On 05/09/2018 04:15, Xu Zaibo wrote:
       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

       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.

At present, It seems no other way existing while being compatible with current logic.
Thank you.

Thanks,
Zaibo






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux