[PATCH 2/2] uacce: add uacce module

zhangfei.gao at foxmail.com zhangfei.gao at foxmail.com
Tue Aug 27 00:33:44 AEST 2019

Hi, Jonathan

On 2019/8/24 上午12:36, Jonathan Cameron wrote:
>>>> Uacce create a chrdev for every registration, the queue is allocated to
>>>> the process when the chrdev is opened. Then the process can access the
>>>> hardware resource by interact with the queue file. By mmap the queue
>>>> file space to user space, the process can directly put requests to the
>>>> hardware without syscall to the kernel space.
>>>> Uacce also manages unify addresses between the hardware and user space
>>>> of the process. So they can share the same virtual address in the
>>>> communication.
>>>> Signed-off-by: Kenneth Lee <liguozhu at hisilicon.com>
>>>> Signed-off-by: Zaibo Xu <xuzaibo at huawei.com>
>>>> Signed-off-by: Zhou Wang <wangzhou1 at hisilicon.com>
>>>> Signed-off-by: Zhangfei Gao <zhangfei.gao at linaro.org>
>>> I would strip this back to which ever case is of most interest (SVA I guess?)
>>> and only think about adding support for the others if necessary at a later date.
>>> (or in later patches).
>> Do you mean split the patch and send sva part first?
> Either:
> 1) SVA only in the first series, second series can do other options.
> 2) Patch N for SVA only, N+1... for other features.
> I don't mind which, but I want to be able to see just one case and
> review that before taking into account the affect of the more complex cases.
OK, understand.
>>>> +static int uacce_set_iommu_domain(struct uacce *uacce)
>>>> +{
>>>> +	struct iommu_domain *domain;
>>>> +	struct iommu_group *group;
>>>> +	struct device *dev = uacce->pdev;
>>>> +	bool resv_msi;
>>>> +	phys_addr_t resv_msi_base = 0;
>>>> +	int ret;
>>>> +
>>>> +	if ((uacce->flags & UACCE_DEV_NOIOMMU) ||
>>>> +	    (uacce->flags & UACCE_DEV_PASID))
>>>> +		return 0;
>>>> +
>>>> +	/*
>>>> +	 * We don't support multiple register for the same dev in RFC version ,
>>>> +	 * will add it in formal version
>>> So this effectively multiple complete uacce interfaces for one device.
>>> Is there a known usecase for that?
>> Here is preventing one device with multiple algorithm and register
>> multi-times,
>> and without sva, they can not be distinguished.
> Isn't that a bug in the device driver?
This should be a limitation for non-pasid case.
With pasid, va can be distinguished for different process.
Without pasid support, uacce_register allocate an UNMANAGED DOMAIN for 
both kernel's and user space's va.
So multi-process is not supported since only one page table.
For the same reason, multi-uacce_register (iommu_domain_alloc) is not 
since va from different domain can not be distinguished.


More information about the Linux-accelerators mailing list