[RFCv2 PATCH 05/36] iommu/process: Bind and unbind process to and from devices
okaya at codeaurora.org
okaya at codeaurora.org
Fri Jan 19 05:07:21 PST 2018
On 2018-01-19 05:27, Jean-Philippe Brucker wrote:
> Hi Sinan,
>
> On 19/01/18 04:52, Sinan Kaya wrote:
>> Hi Jean-Philippe,
>>
>> On 10/6/2017 9:31 AM, Jean-Philippe Brucker wrote:
>>> /**
>>> + * iommu_process_bind_device - Bind a process address space to a
>>> device
>>> + * @dev: the device
>>> + * @task: the process to bind
>>> + * @pasid: valid address where the PASID will be stored
>>> + * @flags: bond properties (IOMMU_PROCESS_BIND_*)
>>> + *
>>> + * Create a bond between device and task, allowing the device to
>>> access the
>>> + * process address space using the returned PASID.
>>> + *
>>> + * On success, 0 is returned and @pasid contains a valid ID.
>>> Otherwise, an error
>>> + * is returned.
>>> + */
>>> +int iommu_process_bind_device(struct device *dev, struct task_struct
>>> *task,
>>> + int *pasid, int flags)
>>
>> This API doesn't play nice with endpoint device drivers that have
>> PASID limitations.
>>
>> The AMD driver seems to have PASID limitations per product that are
>> not being
>> advertised in the PCI capability.
>>
>> device_iommu_pasid_init()
>> {
>> pasid_limit = min_t(unsigned int,
>> (unsigned int)(1 <<
>> kfd->device_info->max_pasid_bits),
>> iommu_info.max_pasids);
>> /*
>> * last pasid is used for kernel queues doorbells
>> * in the future the last pasid might be used for a kernel
>> thread.
>> */
>> pasid_limit = min_t(unsigned int,
>> pasid_limit,
>> kfd->doorbell_process_limit - 1);
>> }
>>
>> kfd->device_info->max_pasid_bits seems to contain per device
>> limitations.
>>
>> Would you be willing to extend the API so that the requester can
>> impose some limit
>> on the PASID value that is getting allocated.
>
> Good point. Following the feedback for this series, next version adds
> another public function:
>
> int iommu_sva_device_init(struct device *dev, int features);
>
> that has to be called by the device driver before any bind(). The
> intent
> is to let some IOMMU drivers initialize PASID tables and other features
> lazily, only if the device driver actually intends to use them. Maybe I
> could change this function to:
>
> int iommu_sva_device_init(struct device *dev, int features, unsigned
> int
> max_pasid);
>
> @features is a bitmask telling what the device driver needs (PASID
> and/or
> page faults). If features has IOMMU_SVA_FEAT_PASID set, then device
> driver
> can set a max_pasid limit, that we'd store in our private device-iommu
> data. If max_pasid is 0, then we'd use the PCI limit.
Yes, this should work.
>
> Thanks,
> Jean
More information about the linux-arm-kernel
mailing list