[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v14 09/22] vfio iommu type1: Add task structure
From: |
Alexey Kardashevskiy |
Subject: |
Re: [Qemu-devel] [PATCH v14 09/22] vfio iommu type1: Add task structure to vfio_dma |
Date: |
Thu, 17 Nov 2016 17:42:11 +1100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
On 17/11/16 17:12, Alex Williamson wrote:
> On Thu, 17 Nov 2016 16:41:14 +1100
> Alexey Kardashevskiy <address@hidden> wrote:
>
>> On 17/11/16 07:46, Kirti Wankhede wrote:
>>> Add task structure to vfio_dma structure. Task structure is used for:
>>> - During DMA_UNMAP, same task who mapped it or other task who shares same
>>> address space is allowed to unmap, otherwise unmap fails.
>>> QEMU maps few iova ranges initially, then fork threads and from the child
>>> thread calls DMA_UNMAP on previously mapped iova. Since child shares same
>>> address space, DMA_UNMAP is successful.
>>> - Avoid accessing struct mm while process is exiting by acquiring
>>> reference of task's mm during page accounting.
>>> - It is also used to get task mlock capability and rlimit for mlock.
>>>
>>> Signed-off-by: Kirti Wankhede <address@hidden>
>>> Signed-off-by: Neo Jia <address@hidden>
>>> Reviewed-by: Dong Jia Shi <address@hidden>
>>
>>
>> I keep whinging that @mm should be referenced, not @current but you keep
>> referencing @current even if you only need @mm and you are not telling why
>> - and I am wondering what I am missing here? Something else will be used
>> from @task later, besides just @mm?
>
> Yes, we reference @current from vfio_dma_do_map() and this is stored
> on the struct vfio_dma. A reference to current is held because the
> external page pinning in vfio_pin_page_external() needs to test the
> capabilities of the task for CAP_IPC_LOCK to know whether locked memory
Ah, that's it - capable(CAP_IPC_LOCK) is checking @current, missed that.
> limits are in effect for the task even when it's not @current (ie. an
> asynchronous call from the vendor driver regardless of what task is
> currently running). There are also various get_task_mm() taken
> temporarily when we're working with the mm of that task. Do you spot
> any issues with this behavior? Thanks,
No, now I am fine, thanks!
--
Alexey
- [Qemu-devel] [PATCH v14 02/22] vfio: VFIO based driver for Mediated devices, (continued)
- [Qemu-devel] [PATCH v14 02/22] vfio: VFIO based driver for Mediated devices, Kirti Wankhede, 2016/11/16
- [Qemu-devel] [PATCH v14 03/22] vfio: Rearrange functions to get vfio_group from dev, Kirti Wankhede, 2016/11/16
- [Qemu-devel] [PATCH v14 01/22] vfio: Mediated device Core driver, Kirti Wankhede, 2016/11/16
- [Qemu-devel] [PATCH v14 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops, Kirti Wankhede, 2016/11/16
- [Qemu-devel] [PATCH v14 06/22] vfio iommu type1: Update arguments of vfio_lock_acct, Kirti Wankhede, 2016/11/16
- [Qemu-devel] [PATCH v14 08/22] vfio iommu type1: Add find_iommu_group() function, Kirti Wankhede, 2016/11/16
- [Qemu-devel] [PATCH v14 04/22] vfio: Common function to increment container_users, Kirti Wankhede, 2016/11/16
- [Qemu-devel] [PATCH v14 09/22] vfio iommu type1: Add task structure to vfio_dma, Kirti Wankhede, 2016/11/16
- [Qemu-devel] [PATCH v14 10/22] vfio iommu type1: Add support for mediated devices, Kirti Wankhede, 2016/11/16
- [Qemu-devel] [PATCH v14 12/22] vfio: Add notifier callback to parent's ops structure of mdev, Kirti Wankhede, 2016/11/16