[PATCH v2] drm/xe/vsec: Allow for kernel context access

[Ruhl, Michael J]

>-----Original Message-----
>From: De Marchi, Lucas <lucas.demarchi at intel.com>
>Sent: Thursday, May 8, 2025 12:43 PM
>To: Ruhl, Michael J <michael.j.ruhl at intel.com>
>Cc: intel-xe at lists.freedesktop.org; Johnstone, Nicholas
><nicholas.johnstone at intel.com>; Box, David E <david.e.box at intel.com>; Vivi,
>Rodrigo <rodrigo.vivi at intel.com>
>Subject: Re: [PATCH v2] drm/xe/vsec: Allow for kernel context access
>
>On Thu, May 08, 2025 at 01:09:06PM +0000, Ruhl, Michael J wrote:
>>>-----Original Message-----
>>>From: De Marchi, Lucas <lucas.demarchi at intel.com>
>>>Sent: Wednesday, May 7, 2025 3:46 PM
>>>To: Ruhl, Michael J <michael.j.ruhl at intel.com>
>>>Cc: intel-xe at lists.freedesktop.org; Johnstone, Nicholas
>>><nicholas.johnstone at intel.com>; Box, David E <david.e.box at intel.com>;
>Vivi,
>>>Rodrigo <rodrigo.vivi at intel.com>
>>>Subject: Re: [PATCH v2] drm/xe/vsec: Allow for kernel context access
>>>
>>>On Wed, May 07, 2025 at 03:37:40PM -0400, Michael J. Ruhl wrote:
>>>>The PMT driver API allows kernel level access to device
>>>
>>>ahn? What's that supposed to mean? what's the context that is calling
>>>this ?
>>
>>Hi Lucas,
>>
>>The PMT exports the pmt_telem_read_mmio() function which accesses HW
>registers
>>for telemetry information.
>>
>>In this use case the SOCwatch kernel driver is accessing the API trying to read
>telemetry
>>information.
>>
>>Since is happening from kernel level rather than user level, the mutex throws
>the
>>"might sleep" context error.
>>
>>I tried to distill this the above comment...  Does adding the content above
>explain this
>>enough, or should I be more expansive (what details do you need?)?
>
>being called from another kernel module doesn't explain anything
>regarding being allowed to sleep or not. Also depending on the context a
>spinlock may not even be sufficient as it may sleep. Without knowing the
>caller we can't even know if it should be a spinlock or a raw_spinlock.

Hmm, I am not sure how I can identify the caller.  The PMT code provides and API for kernel use.

With that in mind, it seems like the only answer is to use raw_spinlock, or if I am understanding
the spinlock_types.h

#if !CONFIG_PREEMPT_RT
	spinlock_t;
#else
	struct raw_spinlock
#end

?

Thanks,

M

>Lucas De Marchi