Re: [PATCH 5/5] drm/xe/vram: add early VRAM health check

[Matthew Brost <matthew.brost@intel.com>]

On Fri, Aug 28, 2026 at 01:32:31PM -0700, Linus Torvalds wrote:
> On Fri, 28 Aug 2026 at 12:58, Matthew Brost <matthew.brost@intel.com> wrote:
> >
> > I think it's OK to go ahead with backporting your patch to stable. I had
> > an open question about whether we wanted to implement the fix slightly
> > differently to avoid asserts triggering elsewhere in the code [1]
> 
> Hmm. That patch is odd.
> 

Yes, a little.

> It says
> 
>  "When VRAM limit (usable_size) is no longer 2M aligned (e.g. because flat
>   CCS storage size rounds it down to 4K)," [...]
> 
> but that was never true, even before my fix. The usable size was
> either 64kB aligned or 128kB aligned - it has *never* been 2M aligned
> as far as I can tell.
> 
> Now, obviously, if alignment never did anything at all (because CCS
> was already completely aligned), then that 2M alignment could be true.
> 
> So maybe the 2M alignment existed in practice, but it was certainly
> never guaranteed by any code, and any 2M assumptions were completely
> bogus long before my fix as far as I can tell.

Yes, this just happened to be true because of the rounded-up 128K
alignment. Nothing actually enforced it, nor was it required.

> 
> But that commit is odd in another way: it changes the  code to do
> something completely different.
> 
> Before, it didn't use "usable_size" at all, it used thje *actual*
> physical size. Which really *was* 2M aligned, becuase I don't think
> Intel has ever sold any other configurations than 16/24/64GB of
> memory.
> 
> So I don't think [1] actually exposes anything in my fix and I think
> the whole 2M limit wrt that code is actually an entirely separate
> issue.

Also correct. Your change prompted us to audit and clean up our code.
That said, with your fix alone and CONFIG_DRM_XE_DEBUG enabled, our old
bogus assertion will trigger, but it is meaningless. In any case, no
production kernel enables this option.

> 
> But I admittedly *really* don't know this hardware very well at all.
> 
> But yes, this kind of "my fix exposed *another* bug" was why I was
> worried about backporting it without further testing.

That was my concern too, but our audit showed that the only issue was a
bogus assertion that fell out. It isn't a blocker for getting your fix
into stable.

Matt

> 
>               Linus