From: "Christian König" <christian.koenig@amd.com>
To: Matthew Brost <matthew.brost@intel.com>,
intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: kenneth.w.graunke@intel.com, lionel.g.landwerlin@intel.com,
jose.souza@intel.com, simona.vetter@ffwll.ch,
thomas.hellstrom@linux.intel.com, boris.brezillon@collabora.com,
airlied@gmail.com, mihail.atanassov@arm.com,
steven.price@arm.com, shashank.sharma@amd.com
Subject: Re: [RFC PATCH 13/29] drm/xe/mmap: Add mmap support for PCI memory barrier
Date: Tue, 19 Nov 2024 11:00:44 +0100 [thread overview]
Message-ID: <ec16da8d-6e1b-4774-93d6-594bc30e2b78@amd.com> (raw)
In-Reply-To: <20241118233757.2374041-14-matthew.brost@intel.com>
Am 19.11.24 um 00:37 schrieb Matthew Brost:
> From: Tejas Upadhyay <tejas.upadhyay@intel.com>
>
> In order to avoid having userspace to use MI_MEM_FENCE,
> we are adding a mechanism for userspace to generate a
> PCI memory barrier with low overhead (avoiding IOCTL call
> as well as writing to VRAM will adds some overhead).
>
> This is implemented by memory-mapping a page as uncached
> that is backed by MMIO on the dGPU and thus allowing userspace
> to do memory write to the page without invoking an IOCTL.
> We are selecting the MMIO so that it is not accessible from
> the PCI bus so that the MMIO writes themselves are ignored,
> but the PCI memory barrier will still take action as the MMIO
> filtering will happen after the memory barrier effect.
>
> When we detect special defined offset in mmap(), We are mapping
> 4K page which contains the last of page of doorbell MMIO range
> to userspace for same purpose.
Well that is quite a hack, but don't you still need a memory barrier
instruction? E.g. m_fence?
And why don't you expose the real doorbell instead of the last (unused?)
page of the MMIO region?
Regards,
Christian.
>
> For user to query special offset we are adding special flag in
> mmap_offset ioctl which needs to be passed as follows,
> struct drm_xe_gem_mmap_offset mmo = {
> .handle = 0, /* this must be 0 */
> .flags = DRM_XE_MMAP_OFFSET_FLAG_PCI_BARRIER,
> };
> igt_ioctl(fd, DRM_IOCTL_XE_GEM_MMAP_OFFSET, &mmo);
> map = mmap(NULL, size, PROT_WRITE, MAP_SHARED, fd, mmo);
>
> Note: Test coverage for this is added by IGT
> https://patchwork.freedesktop.org/series/140368/ here.
> UMD implementing test, once PR is ready will attach with
> this patch.
>
> V6(MAuld)
> - Move physical mmap to fault handler
> - Modify kernel-doc and attach UMD PR when ready
> V5(MAuld)
> - Return invalid early in case of non 4K PAGE_SIZE
> - Format kernel-doc and add note for 4K PAGE_SIZE HW limit
> V4(MAuld)
> - Add kernel-doc for uapi change
> - Restrict page size to 4K
> V3(MAuld)
> - Remove offset defination from UAPI to be able to change later
> - Edit commit message for special flag addition
> V2(MAuld)
> - Add fault handler with dummy page to handle unplug device
> - Add Build check for special offset to be below normal start page
> - Test d3hot, mapping seems to be valid in d3hot as well
> - Add more info to commit message
>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Michal Mrozek <michal.mrozek@intel.com>
> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
> ---
> drivers/gpu/drm/xe/xe_bo.c | 16 ++++-
> drivers/gpu/drm/xe/xe_bo.h | 2 +
> drivers/gpu/drm/xe/xe_device.c | 103 ++++++++++++++++++++++++++++++++-
> include/uapi/drm/xe_drm.h | 29 +++++++++-
> 4 files changed, 147 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 96dbc88b1f55..f948262e607f 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -2138,9 +2138,23 @@ int xe_gem_mmap_offset_ioctl(struct drm_device *dev, void *data,
> XE_IOCTL_DBG(xe, args->reserved[0] || args->reserved[1]))
> return -EINVAL;
>
> - if (XE_IOCTL_DBG(xe, args->flags))
> + if (XE_IOCTL_DBG(xe, args->flags &
> + ~DRM_XE_MMAP_OFFSET_FLAG_PCI_BARRIER))
> return -EINVAL;
>
> + if (args->flags & DRM_XE_MMAP_OFFSET_FLAG_PCI_BARRIER) {
> + if (XE_IOCTL_DBG(xe, args->handle))
> + return -EINVAL;
> +
> + if (XE_IOCTL_DBG(xe, PAGE_SIZE > SZ_4K))
> + return -EINVAL;
> +
> + BUILD_BUG_ON(((XE_PCI_BARRIER_MMAP_OFFSET >> XE_PTE_SHIFT) +
> + SZ_4K) >= DRM_FILE_PAGE_OFFSET_START);
> + args->offset = XE_PCI_BARRIER_MMAP_OFFSET;
> + return 0;
> + }
> +
> gem_obj = drm_gem_object_lookup(file, args->handle);
> if (XE_IOCTL_DBG(xe, !gem_obj))
> return -ENOENT;
> diff --git a/drivers/gpu/drm/xe/xe_bo.h b/drivers/gpu/drm/xe/xe_bo.h
> index 7fa44a0138b0..e7724965d3f1 100644
> --- a/drivers/gpu/drm/xe/xe_bo.h
> +++ b/drivers/gpu/drm/xe/xe_bo.h
> @@ -63,6 +63,8 @@
>
> #define XE_BO_PROPS_INVALID (-1)
>
> +#define XE_PCI_BARRIER_MMAP_OFFSET (0x50 << XE_PTE_SHIFT)
> +
> struct sg_table;
>
> struct xe_bo *xe_bo_alloc(void);
> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index 930bb2750e2e..f6069db795e7 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -231,12 +231,113 @@ static long xe_drm_compat_ioctl(struct file *file, unsigned int cmd, unsigned lo
> #define xe_drm_compat_ioctl NULL
> #endif
>
> +static void barrier_open(struct vm_area_struct *vma)
> +{
> + drm_dev_get(vma->vm_private_data);
> +}
> +
> +static void barrier_close(struct vm_area_struct *vma)
> +{
> + drm_dev_put(vma->vm_private_data);
> +}
> +
> +static void barrier_release_dummy_page(struct drm_device *dev, void *res)
> +{
> + struct page *dummy_page = (struct page *)res;
> +
> + __free_page(dummy_page);
> +}
> +
> +static vm_fault_t barrier_fault(struct vm_fault *vmf)
> +{
> + struct drm_device *dev = vmf->vma->vm_private_data;
> + struct vm_area_struct *vma = vmf->vma;
> + vm_fault_t ret = VM_FAULT_NOPAGE;
> + pgprot_t prot;
> + int idx;
> +
> + prot = vm_get_page_prot(vma->vm_flags);
> +
> + if (drm_dev_enter(dev, &idx)) {
> + unsigned long pfn;
> +
> +#define LAST_DB_PAGE_OFFSET 0x7ff001
> + pfn = PHYS_PFN(pci_resource_start(to_pci_dev(dev->dev), 0) +
> + LAST_DB_PAGE_OFFSET);
> + ret = vmf_insert_pfn_prot(vma, vma->vm_start, pfn,
> + pgprot_noncached(prot));
> + drm_dev_exit(idx);
> + } else {
> + struct page *page;
> +
> + /* Allocate new dummy page to map all the VA range in this VMA to it*/
> + page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> + if (!page)
> + return VM_FAULT_OOM;
> +
> + /* Set the page to be freed using drmm release action */
> + if (drmm_add_action_or_reset(dev, barrier_release_dummy_page, page))
> + return VM_FAULT_OOM;
> +
> + ret = vmf_insert_pfn_prot(vma, vma->vm_start, page_to_pfn(page),
> + prot);
> + }
> +
> + return ret;
> +}
> +
> +static const struct vm_operations_struct vm_ops_barrier = {
> + .open = barrier_open,
> + .close = barrier_close,
> + .fault = barrier_fault,
> +};
> +
> +static int xe_pci_barrier_mmap(struct file *filp,
> + struct vm_area_struct *vma)
> +{
> + struct drm_file *priv = filp->private_data;
> + struct drm_device *dev = priv->minor->dev;
> +
> + if (vma->vm_end - vma->vm_start > SZ_4K)
> + return -EINVAL;
> +
> + if (is_cow_mapping(vma->vm_flags))
> + return -EINVAL;
> +
> + if (vma->vm_flags & (VM_READ | VM_EXEC))
> + return -EINVAL;
> +
> + vm_flags_clear(vma, VM_MAYREAD | VM_MAYEXEC);
> + vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP | VM_IO);
> + vma->vm_ops = &vm_ops_barrier;
> + vma->vm_private_data = dev;
> + drm_dev_get(vma->vm_private_data);
> +
> + return 0;
> +}
> +
> +static int xe_mmap(struct file *filp, struct vm_area_struct *vma)
> +{
> + struct drm_file *priv = filp->private_data;
> + struct drm_device *dev = priv->minor->dev;
> +
> + if (drm_dev_is_unplugged(dev))
> + return -ENODEV;
> +
> + switch (vma->vm_pgoff) {
> + case XE_PCI_BARRIER_MMAP_OFFSET >> XE_PTE_SHIFT:
> + return xe_pci_barrier_mmap(filp, vma);
> + }
> +
> + return drm_gem_mmap(filp, vma);
> +}
> +
> static const struct file_operations xe_driver_fops = {
> .owner = THIS_MODULE,
> .open = drm_open,
> .release = drm_release_noglobal,
> .unlocked_ioctl = xe_drm_ioctl,
> - .mmap = drm_gem_mmap,
> + .mmap = xe_mmap,
> .poll = drm_poll,
> .read = drm_read,
> .compat_ioctl = xe_drm_compat_ioctl,
> diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> index 4a8a4a63e99c..6490b16b1217 100644
> --- a/include/uapi/drm/xe_drm.h
> +++ b/include/uapi/drm/xe_drm.h
> @@ -811,6 +811,32 @@ struct drm_xe_gem_create {
>
> /**
> * struct drm_xe_gem_mmap_offset - Input of &DRM_IOCTL_XE_GEM_MMAP_OFFSET
> + *
> + * The @flags can be:
> + * - %DRM_XE_MMAP_OFFSET_FLAG_PCI_BARRIER - For user to query special offset
> + * for use in mmap ioctl. Writing to the returned mmap address will generate a
> + * PCI memory barrier with low overhead (avoiding IOCTL call as well as writing
> + * to VRAM which would also add overhead), acting like an MI_MEM_FENCE
> + * instruction.
> + *
> + * Note: The mmap size can be at most 4K, due to HW limitations. As a result
> + * this interface is only supported on CPU architectures that support 4K page
> + * size. The mmap_offset ioctl will detect this and gracefully return an
> + * error, where userspace is expected to have a different fallback method for
> + * triggering a barrier.
> + *
> + * Roughly the usage would be as follows:
> + *
> + * .. code-block:: C
> + *
> + * struct drm_xe_gem_mmap_offset mmo = {
> + * .handle = 0, // must be set to 0
> + * .flags = DRM_XE_MMAP_OFFSET_FLAG_PCI_BARRIER,
> + * };
> + *
> + * err = ioctl(fd, DRM_IOCTL_XE_GEM_MMAP_OFFSET, &mmo);
> + * map = mmap(NULL, size, PROT_WRITE, MAP_SHARED, fd, mmo.offset);
> + * map[i] = 0xdeadbeaf; // issue barrier
> */
> struct drm_xe_gem_mmap_offset {
> /** @extensions: Pointer to the first extension struct, if any */
> @@ -819,7 +845,8 @@ struct drm_xe_gem_mmap_offset {
> /** @handle: Handle for the object being mapped. */
> __u32 handle;
>
> - /** @flags: Must be zero */
> +#define DRM_XE_MMAP_OFFSET_FLAG_PCI_BARRIER (1 << 0)
> + /** @flags: Flags */
> __u32 flags;
>
> /** @offset: The fake offset to use for subsequent mmap call */
next prev parent reply other threads:[~2024-11-19 10:00 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 23:37 [RFC PATCH 00/29] UMD direct submission in Xe Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 01/29] dma-fence: Add dma_fence_preempt base class Matthew Brost
2024-11-20 13:31 ` Christian König
2024-11-20 17:36 ` Matthew Brost
2024-11-21 10:04 ` Christian König
2024-11-21 18:41 ` Matthew Brost
2024-11-22 10:56 ` Christian König
2024-11-18 23:37 ` [RFC PATCH 02/29] dma-fence: Add dma_fence_user_fence Matthew Brost
2024-11-20 13:38 ` Christian König
2024-11-20 22:50 ` Matthew Brost
2024-11-21 9:31 ` Christian König
2024-11-22 2:35 ` Matthew Brost
2024-11-22 10:28 ` Christian König
2024-11-18 23:37 ` [RFC PATCH 03/29] drm/xe: Use dma_fence_preempt base class Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 04/29] drm/xe: Allocate doorbells for UMD exec queues Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 05/29] drm/xe: Add doorbell ID to snapshot capture Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 06/29] drm/xe: Break submission ring out into its own BO Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 07/29] drm/xe: Break indirect ring state " Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 08/29] drm/xe: Clear GGTT in xe_bo_restore_kernel Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 09/29] FIXME: drm/xe: Add pad to ring and indirect state Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 10/29] drm/xe: Enable indirect ring on media GT Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 11/29] drm/xe: Don't add pinned mappings to VM bulk move Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 12/29] drm/xe: Add exec queue post init extension processing Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 13/29] drm/xe/mmap: Add mmap support for PCI memory barrier Matthew Brost
2024-11-19 10:00 ` Christian König [this message]
2024-11-19 11:57 ` Joonas Lahtinen
2024-11-19 12:42 ` Mrozek, Michal
2024-12-18 12:59 ` Upadhyay, Tejas
2024-11-18 23:37 ` [RFC PATCH 14/29] drm/xe: Add support for mmapping doorbells to user space Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 15/29] drm/xe: Add support for mmapping submission ring and indirect ring state " Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 16/29] drm/xe/uapi: Define UMD exec queue mapping uAPI Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 17/29] drm/xe: Add usermap exec queue extension Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 18/29] drm/xe: Drop EXEC_QUEUE_FLAG_UMD_SUBMISSION flag Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 19/29] drm/xe: Do not allow usermap exec queues in exec IOCTL Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 20/29] drm/xe: Teach GuC backend to kill usermap queues Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 21/29] drm/xe: Enable preempt fences on " Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 22/29] drm/xe/uapi: Add uAPI to convert user semaphore to / from drm syncobj Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 23/29] drm/xe: Add user fence IRQ handler Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 24/29] drm/xe: Add xe_hw_fence_user_init Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 25/29] drm/xe: Add a message lock to the Xe GPU scheduler Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 26/29] drm/xe: Always wait on preempt fences in vma_check_userptr Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 27/29] drm/xe: Teach xe_sync layer about drm_xe_semaphore Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 28/29] drm/xe: Add VM convert fence IOCTL Matthew Brost
2024-11-18 23:37 ` [RFC PATCH 29/29] drm/xe: Add user fence TDR Matthew Brost
2024-11-18 23:55 ` ✓ CI.Patch_applied: success for UMD direct submission in Xe Patchwork
2024-11-18 23:56 ` ✗ CI.checkpatch: warning " Patchwork
2024-11-18 23:57 ` ✓ CI.KUnit: success " Patchwork
2024-11-19 0:15 ` ✓ CI.Build: " Patchwork
2024-11-19 0:17 ` ✗ CI.Hooks: failure " Patchwork
2024-11-19 0:19 ` ✓ CI.checksparse: success " Patchwork
2024-11-19 0:39 ` ✗ CI.BAT: failure " Patchwork
2024-11-19 11:44 ` ✗ CI.FULL: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ec16da8d-6e1b-4774-93d6-594bc30e2b78@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jose.souza@intel.com \
--cc=kenneth.w.graunke@intel.com \
--cc=lionel.g.landwerlin@intel.com \
--cc=matthew.brost@intel.com \
--cc=mihail.atanassov@arm.com \
--cc=shashank.sharma@amd.com \
--cc=simona.vetter@ffwll.ch \
--cc=steven.price@arm.com \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox