All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
To: Jeffrey Hugo <quic_jhugo@quicinc.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: Tue, 9 Jan 2024 13:50:42 +0100	[thread overview]
Message-ID: <55a27434-7de7-41af-a86f-4991e51de2c4@linux.intel.com> (raw)
In-Reply-To: <c1817603-e789-35e6-d1f0-ae243f71af24@quicinc.com>

On 05.01.2024 16:32, Jeffrey Hugo wrote:
> 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"

Sure

>> 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?

There were multiple occasions were these messages were useful:
  - Debugging IOMMU issues on pre-production hardware
  - Enabling DevTLB cache on a functional simulator
  - Debugging performance issues with fragmented buffers

There is always some security tradeoff when enabling debug features but in this case it seems to be worth it.



  reply	other threads:[~2024-01-09 12:51 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
2024-01-09 12:50     ` Jacek Lawrynowicz [this message]
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=55a27434-7de7-41af-a86f-4991e51de2c4@linux.intel.com \
    --to=jacek.lawrynowicz@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=karol.wachowski@intel.com \
    --cc=quic_jhugo@quicinc.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.