[PATCH v2] drm/xe/uapi: Bring back reset uevent

[Aravind Iddamsetty]

On 14/08/24 19:54, Lucas De Marchi wrote:
> On Wed, Aug 14, 2024 at 12:16:41PM GMT, Aravind Iddamsetty wrote:
>>>>> i see that this is even called from xe_guc_exec_queue_lr_cleanup which is for long running queue
>>>>> from various call paths need to check in what scenarios those happen.
>>>> Should we add a reason for long running queue?
>>> Both of your questions would probably be answered if this was getting developed
>>> at the same time of the user space usage of these uevents.
>>
>> Can't we consider the generic Linux user as a consumer, via udevadm.
>
> No, udevadm just confirms that there is an event being sent. Main thing
> to understand here is "what is this event useful for? what can be done
> as outcome of receiving this event?". From your other reply it seems
> this is about "device is wedged/toast, and driver can't recover without
> userspace intervention since userspace may have different policies"
>
> What would be some examples of actions for userspace to take?
>
>     - Unbind driver, kill clients, rebind?
>     - FLR?
>     - Something else?

The expectation from userspace on receiving this event is to do a reset
most probably SBR(unbind->sbr->rebind).

The other requirement of this event is for L0 Sysman

https://spec.oneapi.io/level-zero/latest/sysman/api.html#_CPPv4N21zes_event_type_flag_t41ZES_EVENT_TYPE_FLAG_DEVICE_RESET_REQUIREDE

https://spec.oneapi.io/level-zero/latest/sysman/api.html#_CPPv4N18zes_device_state_t5resetE

So we expect the admin do the above actions

>
> Is this currently implemented somewhere?
Do you mean by some other driver or subsystem?
>
> Also, is it possible to make is a generic drm event handling so distros
> don't have to setup udev rules for each vendor?

I think doing via drm event mandates the observability applications(L0)
to have open connection to the device to process these which is not desired.

Thanks,
Aravind.
>
>
>
> Lucas De Marchi
>
>>
>> Thanks,
>> Aravind.
>>>
>>>> Raag