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

Jean-Philippe Brucker
2018-09-05T11:02:29Z

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.

Thanks,
Jean