On Fri, Apr 12, 2024 at 08:47:10PM -0700, Nicolin Chen wrote:
> Add for sharing the kernel page with user space. This allows to pass
> through HW resource (VCMDQ MMIO pages for example) to user space VMM
> and guest OS. Use vma->vm_pgoff as the carrier of a viommu_id.
>
> Signed-off-by: Nicolin Chen <nicolinc@xxxxxxxxxx>
> ---
> drivers/iommu/iommufd/main.c | 40 ++++++++++++++++++++++++++++++++++++
> include/linux/iommufd.h | 4 ++++
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/iommu/iommufd/main.c b/drivers/iommu/iommufd/main.c
> index 96ef81530809..5b401c80cca8 100644
> --- a/drivers/iommu/iommufd/main.c
> +++ b/drivers/iommu/iommufd/main.c
> @@ -16,6 +16,7 @@
> #include <linux/mutex.h>
> #include <linux/bug.h>
> #include <uapi/linux/iommufd.h>
> +#include <linux/iommu.h>
> #include <linux/iommufd.h>
>
> #include "io_pagetable.h"
> @@ -427,11 +428,50 @@ static long iommufd_fops_ioctl(struct file *filp, unsigned int cmd,
> return ret;
> }
>
> +static int iommufd_fops_mmap(struct file *filp, struct vm_area_struct *vma)
> +{
> + struct iommufd_ctx *ictx = filp->private_data;
> + size_t size = vma->vm_end - vma->vm_start;
> + u32 viommu_id = (u32)vma->vm_pgoff;
Don't do mmaps this way, it doesn't scale well for future things.
The pgoff/length should *always* come from the kernel as some
'mmap_offset' output. I usually call this the mmap cookie.
In this case have the mmap cookie for the tegra doorbell return in the
viommu's driver data struct, then userspace just passes the opaque
cookie to mmap to get the correct tegra doorbell.
The core code has some simple xarray/maple tree to allocate cookies
and dispatch them to the correct mmap callback. Usually I'd say to
provide a mmap callback pointer when allocating the cookie.
Also look at the RDMA Code around mmap there is a bunch of VMA
validations needed. Ie we must insist on VM_SHARED and check
permissions, etc.
Jason
