[igt-dev] [PATCH i-g-t] tests/xe add invalid va access tests

[Chang, Yu bruce]

> -----Original Message-----
> From: Welty, Brian <brian.welty at intel.com>
> Sent: Wednesday, August 30, 2023 6:11 PM
> To: Chang, Yu bruce <yu.bruce.chang at intel.com>; igt-
> dev at lists.freedesktop.org
> Cc: Zeng, Oak <oak.zeng at intel.com>; Vishwanathapura, Niranjana
> <niranjana.vishwanathapura at intel.com>; Brost, Matthew
> <matthew.brost at intel.com>
> Subject: Re: [PATCH i-g-t] tests/xe add invalid va access tests
> On 8/30/2023 5:26 PM, Chang, Yu bruce wrote:
> >>
> >> Do we need some verification here that driver did proper thing when
> >> encountering invalid va.  Meaning there was some different behavior
> >> with scratch page we can observe?
> >> Without DRM_XE_VM_CREATE_SCRATCH_PAGE, program is terminated?
> Are we
> >> banning the context like i915 was doing?
> >>
> >
> > Good point, now is a manual check for the log for a reset message, I
> > can look into To automate it.
> >
> 
> Isn't the xe_wait_ufence() supposed to somehow inform that something
> actually failed with the xe_exec?
> I notice you are using _xe_wait_ufence instead of xe_wait_ufence().
> It gives an error?
> 
> You mentioned that the engine was reset....  was is the effect of that?
> Maybe a subsequent xe_exec() will fail?   Just grasping at some
> user-space visible things you can try easily.  I don't know myself, new code...
> 
> -Brian
> 
Actually the reset is just to make sure the existing stuck command got
cleaned up. The next command should still go through.

The v3 patch now can validate the return code from _xe_wait_ufence.
It now only have ETIME and 0.
There is a separate follow up task to include reset, Banned, or other error code.

-Bruce