All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeffrey Hugo <quic_jhugo@quicinc.com>
To: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
	<dri-devel@lists.freedesktop.org>
Cc: "Wachowski, Karol" <karol.wachowski@intel.com>
Subject: Re: [PATCH 03/10] accel/ivpu: Add debug prints for MMU map/unmap operations
Date: Fri, 5 Jan 2024 08:32:08 -0700	[thread overview]
Message-ID: <c1817603-e789-35e6-d1f0-ae243f71af24@quicinc.com> (raw)
In-Reply-To: <20240105112218.351265-4-jacek.lawrynowicz@linux.intel.com>

On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:
> From: "Wachowski, Karol" <karol.wachowski@intel.com>
> 
> It is common need to be able to  see IOVA/physical to VPU addresses

Errant double space between "to" and "see"

> mappings. Especially when debugging different kind of memory related
> issues. Lack of such logs forces user to modify and recompile KMD manually.
> 
> This commit adds those logs under MMU debug mask which can be turned on
> dynamically with module param during KMD load.
As far as I understand, the preference is to not expose any kind of raw 
addresses as it is seen as a security issue, and usually the addresses 
don't have any real value to someone reading logs, etc.  I beleive I 
picked this up from GregKH.

However, this commit text suggests there is value, and I see that one 
needs to be root to enable this which could probably be considered a 
sufficent gate to avoiding the data getting into the wrong hands.

Is it possible to provide more details as a justification for this? 
Perhaps an example of a past issue where this data was necessary for debug?

> 
> Signed-off-by: Wachowski, Karol <karol.wachowski@intel.com>
> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
> ---
>   drivers/accel/ivpu/ivpu_drv.h         | 1 +
>   drivers/accel/ivpu/ivpu_mmu_context.c | 9 +++++++++
>   2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
> index ebc4b84f27b2..9b6e336626e3 100644
> --- a/drivers/accel/ivpu/ivpu_drv.h
> +++ b/drivers/accel/ivpu/ivpu_drv.h
> @@ -56,6 +56,7 @@
>   #define IVPU_DBG_JSM	 BIT(10)
>   #define IVPU_DBG_KREF	 BIT(11)
>   #define IVPU_DBG_RPM	 BIT(12)
> +#define IVPU_DBG_MMU_MAP BIT(13)
>   
>   #define ivpu_err(vdev, fmt, ...) \
>   	drm_err(&(vdev)->drm, "%s(): " fmt, __func__, ##__VA_ARGS__)
> diff --git a/drivers/accel/ivpu/ivpu_mmu_context.c b/drivers/accel/ivpu/ivpu_mmu_context.c
> index 12a8c09d4547..fe6161299236 100644
> --- a/drivers/accel/ivpu/ivpu_mmu_context.c
> +++ b/drivers/accel/ivpu/ivpu_mmu_context.c
> @@ -355,6 +355,9 @@ ivpu_mmu_context_map_sgt(struct ivpu_device *vdev, struct ivpu_mmu_context *ctx,
>   		dma_addr_t dma_addr = sg_dma_address(sg) - sg->offset;
>   		size_t size = sg_dma_len(sg) + sg->offset;
>   
> +		ivpu_dbg(vdev, MMU_MAP, "Map ctx: %u dma_addr: 0x%llx vpu_addr: 0x%llx size: %lu\n",
> +			 ctx->id, dma_addr, vpu_addr, size);
> +
>   		ret = ivpu_mmu_context_map_pages(vdev, ctx, vpu_addr, dma_addr, size, prot);
>   		if (ret) {
>   			ivpu_err(vdev, "Failed to map context pages\n");
> @@ -366,6 +369,7 @@ ivpu_mmu_context_map_sgt(struct ivpu_device *vdev, struct ivpu_mmu_context *ctx,
>   
>   	/* Ensure page table modifications are flushed from wc buffers to memory */
>   	wmb();
> +

This looks like an unrelated whitespace change (although I see it pairs 
with the whitespace change below).

>   	mutex_unlock(&ctx->lock);
>   
>   	ret = ivpu_mmu_invalidate_tlb(vdev, ctx->id);
> @@ -388,14 +392,19 @@ ivpu_mmu_context_unmap_sgt(struct ivpu_device *vdev, struct ivpu_mmu_context *ct
>   	mutex_lock(&ctx->lock);
>   
>   	for_each_sgtable_dma_sg(sgt, sg, i) {
> +		dma_addr_t dma_addr = sg_dma_address(sg) - sg->offset;
>   		size_t size = sg_dma_len(sg) + sg->offset;
>   
> +		ivpu_dbg(vdev, MMU_MAP, "Unmap ctx: %u dma_addr: 0x%llx vpu_addr: 0x%llx size: %lu\n",
> +			 ctx->id, dma_addr, vpu_addr, size);
> +
>   		ivpu_mmu_context_unmap_pages(ctx, vpu_addr, size);
>   		vpu_addr += size;
>   	}
>   
>   	/* Ensure page table modifications are flushed from wc buffers to memory */
>   	wmb();
> +

This looks like an unrelated whitespace change.

>   	mutex_unlock(&ctx->lock);
>   
>   	ret = ivpu_mmu_invalidate_tlb(vdev, ctx->id);


  reply	other threads:[~2024-01-05 15:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-05 11:22 [PATCH 00/10] accel/ivpu fixes for 6.8 Jacek Lawrynowicz
2024-01-05 11:22 ` [PATCH 01/10] accel/ivpu: Dump MMU events in case of VPU boot timeout Jacek Lawrynowicz
2024-01-05 15:11   ` Jeffrey Hugo
2024-01-05 11:22 ` [PATCH 02/10] accel/ivpu: Call diagnose failure in ivpu_mmu_cmdq_sync() Jacek Lawrynowicz
2024-01-05 15:12   ` Jeffrey Hugo
2024-01-05 11:22 ` [PATCH 03/10] accel/ivpu: Add debug prints for MMU map/unmap operations Jacek Lawrynowicz
2024-01-05 15:32   ` Jeffrey Hugo [this message]
2024-01-09 12:50     ` Jacek Lawrynowicz
2024-01-05 11:22 ` [PATCH 04/10] accel/ivpu: Add diagnostic messages when VPU fails to boot or suspend Jacek Lawrynowicz
2024-01-05 15:41   ` Jeffrey Hugo
2024-01-05 11:22 ` [PATCH 05/10] accel/ivpu: Fix potential infinite loops in IRQ handlers Jacek Lawrynowicz
2024-01-05 16:35   ` Jeffrey Hugo
2024-01-09 12:34     ` Jacek Lawrynowicz
2024-01-05 11:22 ` [PATCH 06/10] accel/ivpu: Fix for missing lock around drm_gem_shmem_vmap() Jacek Lawrynowicz
2024-01-05 16:36   ` Jeffrey Hugo
2024-01-09 12:51     ` Jacek Lawrynowicz
2024-01-05 11:22 ` [PATCH 07/10] accel/ivpu: Free buffer sgt on unbind Jacek Lawrynowicz
2024-01-05 16:37   ` Jeffrey Hugo
2024-01-05 11:22 ` [PATCH 08/10] accel/ivpu: Disable buffer sharing among VPU contexts Jacek Lawrynowicz
2024-01-05 16:46   ` Jeffrey Hugo
2024-01-10 10:53     ` Jacek Lawrynowicz
2024-01-05 22:34   ` Carl Vanderlip
2024-01-10 10:54     ` Jacek Lawrynowicz
2024-01-05 11:22 ` [PATCH 09/10] accel/ivpu: Improve buffer object debug logs Jacek Lawrynowicz
2024-01-05 17:03   ` Jeffrey Hugo
2024-01-10 11:08     ` Jacek Lawrynowicz
2024-01-05 11:22 ` [PATCH 10/10] accel/ivpu: Remove deprecated DRM_IVPU_PARAM_CONTEXT_PRIORITY Jacek Lawrynowicz
2024-01-05 17:29   ` Jeffrey Hugo
2024-01-10 14:33     ` Jacek Lawrynowicz
2024-01-11 21:03       ` Jeffrey Hugo

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=c1817603-e789-35e6-d1f0-ae243f71af24@quicinc.com \
    --to=quic_jhugo@quicinc.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jacek.lawrynowicz@linux.intel.com \
    --cc=karol.wachowski@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.