Re: [PATCH v2] drm/xe/guc: Demote uncorrectable local error log to info

["Summers, Stuart" <stuart.summers@intel.com>]

On Tue, 2026-09-29 at 12:02 -0700, Matt Roper wrote:
> On Fri, Sep 18, 2026 at 10:35:36AM -0400, Rodrigo Vivi wrote:
> > On Fri, Sep 18, 2026 at 09:50:48AM +0200, Michal Wajdeczko wrote:
> > > 
> > > 
> > > On 9/17/2026 3:53 PM, Varun Gupta wrote:
> > > > The UNCORRECTABLE_LOCAL_ERROR notification sent by the GuC
> > > > indicates a
> > > > local, queue-level context termination rather than a global
> > > > device or
> > > > driver failure. This can be triggered as part of expected
> > > > recovery flows,
> > > > including intentional fault-injection tests.
> > > > 
> > > > Printing this at ERROR level is too noisy and causes false-
> > > > positive
> > > > dmesg-warn failures in CI. Switch the log level to INFO,
> > > > matching the
> > > > adjacent CAT error handler.
> > > > 
> > > > v2:
> > > >   - Also ratelimit the GUC_ID_UNKNOWN to match the CAT error
> > > > handler.
> > > >     (Himal)
> > > > 
> > > > Fixes: 4e57574fa3a3 ("drm/xe/guc: Handle GuC local
> > > > uncorrectable error notifications")
> > > > Signed-off-by: Varun Gupta <varun.gupta@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/xe/xe_guc_submit.c | 8 ++++----
> > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > b/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > index f3ba8abfc228..6144a1767f10 100644
> > > > --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > @@ -3487,7 +3487,7 @@ int
> > > > xe_guc_uncorrectable_error_handler(struct xe_guc *guc, u32
> > > > *msg, u32 len)
> > > >         guc_id = msg[0];
> > > >  
> > > >         if (guc_id == GUC_ID_UNKNOWN) {
> > > 
> > > btw, shouldn't we check for guc_id >= GUC_ID_UNKNOWN?
> > > 
> > > > -               xe_gt_err(gt, "GuC: Uncorrectable local error
> > > > with unknown GuC id\n");
> > > > +               xe_gt_err_ratelimited(gt, "GuC: Uncorrectable
> > > > local error with unknown GuC id\n");
> > > >                 return 0;
> > > 
> > > if GuC shouldn't ever pass invalid guc-id here, as spec says this
> > > action is for:
> > > 
> > >         "Notify the context which caused an uncorrectable local
> > > error to KMD"
> > > 
> > > then IMO instead of ratelimiting this error, we should rather
> > > escalate this
> > > to -EPROTO to force the error dump and reset from the CTB layer,
> > > no? 
> > 
> > Himal, next time please do not rush with committing patches like
> > this.
> > 
> > There were 2 unadressed comments in it.
> > 
> > > 
> > > >         }
> > > >  
> > > > @@ -3495,9 +3495,9 @@ int
> > > > xe_guc_uncorrectable_error_handler(struct xe_guc *guc, u32
> > > > *msg, u32 len)
> > > >         if (unlikely(!q))
> > > >                 return -EPROTO;
> > > >  
> > > > -       xe_gt_err(gt,
> > > > -                 "GuC: Uncorrectable local error! guc_id=%d
> > > > class=%s, logical_mask=0x%x",
> > > > -                 guc_id, xe_hw_engine_class_to_str(q->class),
> > > > q->logical_mask);
> > > > +       xe_gt_info(gt,
> > 
> > Again, this is a no no!
> > 
> > This is not a CAT ERROR that is expected in any page fault caused
> > by the user.
> > If we hit this case it is a guc identified uncorrectable error!
> 
> I think this is the problem here --- according to the hardware
> people,
> any cat error triggered by an unhandled pagefault *always* generates
> an
> uncorrectable error on platforms like CRI that support the new RAS
> flows.  That means that we absolutely cannot allow these dmesg prints
> to
> be generated at any log level higher than debug (I believe even the
> change to 'info' level here is insufficient).  Otherwise we've given
> unprivileged userspace a way to directly trigger new entries into the
> dmesg log, and that's generally considered a security vulnerability.
> 
> It really seems wrong to me that hardware is raising uncorrectable
> errors on all cat errors.  I think we really need to double/triple
> confirm this with the hardware teams and make sure that this is truly
> what they expected to happen.  But if it is, then we absolutely need
> to
> downgrade the dmesg printing here because we can't give userspace a
> way
> to trigger non-debug log entries on demand like this.
> 
> We may also want to file some tickets against the hardware teams to
> see
> if they can rethink this behavior on future platforms, or make it
> software configurable.

I agree we should push this back. Since these are sent up from GuC,
maybe we let GuC do the filtering before it ever hits the KMD?

I don't like the idea of moving uncorrectable errors to info/debug
classification. But I also agree we don't want to mark all user-level
CAT faults as error messages since this is expected for application
bugs (or intentional CI tests).

I definitely don't want to see something like this merged without
proper review though. And ideally we should have bspec references
indicating all CAT errors will generate a local uncorrectable error.
Otherwise IMO this is a bug in GuC at least that we shouldn't be
papering over in the KMD.

Thanks,
Stuart

> 
> 
> Matt
> 
> > 
> > Only come back with this idea if we can really justify why you can
> > demote **all**
> > guc uncoorrectable errors to this.
> > 
> > The errors you mentioned in the commit message are not a good
> > reason and should
> > be handled by the testing tools.
> > 
> > The patch was removed from the drm-xe-next. Please get back to the
> > drawing board.
> > 
> > Thanks,
> > Rodrigo.
> > 
> > > > +                  "GuC: Uncorrectable local error! guc_id=%d
> > > > class=%s, logical_mask=0x%x",
> > > > +                  guc_id, xe_hw_engine_class_to_str(q->class),
> > > > q->logical_mask);
> > > >  
> > > >         trace_xe_guc_uncorrectable_error(q);
> > > >  
> > > 
>