From: Matthew Brost <matthew.brost@intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: intel-xe@lists.freedesktop.org,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
stable@kernel.org
Subject: Re: [PATCH 3/5] drm/xe/vram: report FLAT_CCS base misalignment
Date: Tue, 1 Sep 2026 13:10:52 -0700 [thread overview]
Message-ID: <apcxTIDGDPtBARau@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <93751687-9f80-4182-80c7-c407346d5bae@intel.com>
On Tue, Sep 01, 2026 at 09:23:22AM +0100, Matthew Auld wrote:
> On 28/08/2026 21:10, Matthew Brost wrote:
> > On Fri, Aug 28, 2026 at 04:14:09PM +0100, Matthew Auld wrote:
> > > So we can easily check if a machine had the CCS bug, when looking back
> > > over bug reports where we have the same machine with newer kernel.
> > >
> >
> > I'm a little confused about how this helps, so I'm thinking out loud here:
> > - On old kernels without Linus's CCS fix or this patch, there is no
> > message and we get silent corruption if the affected memory belongs to
> > user space. Of course, things fall apart completely if the corruption
> > affects kernel memory, as in the case Linus hit.
> > - On new kernels with Linus's CCS fix plus this patch, does this message
> > appear under load on some configurations, or on all configurations?
>
> Yeah, this is logged before the round_down(offset, 4K). On my b570, for
> example, I get a nice dmesg print to indicate that this machine had the bug
> (fix from Linus also applied). In our CI farm, there is no print, since
> nothing seems to have this bug, also confirms the memtest is not just
> missing the issue somehow. But not sure about wider RIL, I assume something
> in there maybe has this bug.
>
> >
> > Is the idea that the first thing we check for is whether this message is
> > present?
>
> Yeah, just a record in dmesg of whether the device had this CCS bug, when
> looking at bug reports. The memtest is also gated behind debug builds, for
> now. For example, some older bug report with impossible corruption or other
> weird stuff, update to latest stable or tip and issue seems to go away.
> Would be good to confirm if this machine had the CCS bug. Users might also
> want to check this.
>
> > Would it be better to simply print the FLAT_CCS base address along with
> > a field indicating whether it is misaligned? That would let us quickly
> > determine, across all devices, whether the CCS base is aligned or
> > misaligned and if the CCS fix is present.
>
> Could print the address also. Happy to do either approach.
>
I think just delete the 'if (!IS_ALIGNED(offset, SZ_128K))' gate and
print the CCS info + flag a misalignment.
Matt
> >
> > Matt
> >
> > > Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation")
> > > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: stable@kernel.org
> > > ---
> > > drivers/gpu/drm/xe/xe_vram.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c
> > > index 7b4478fb1697..0a2f1ab8416e 100644
> > > --- a/drivers/gpu/drm/xe/xe_vram.c
> > > +++ b/drivers/gpu/drm/xe/xe_vram.c
> > > @@ -90,6 +90,9 @@ static int get_flat_ccs_offset(struct xe_gt *gt, u64 tile_size, u64 *poffset)
> > > offset |= offset_lo << 6; /* HW view bits 31:6 */
> > > offset *= num_enabled; /* convert to SW view */
> > > + if (!IS_ALIGNED(offset, SZ_128K))
> > > + drm_info(&xe->drm, "FLAT_CCS base misaligned: %llx\n", offset);
> > > +
> > > /*
> > > * Everything below this offset is handed to the VRAM
> > > * allocator, so it has to be the *first* address the
> > > --
> > > 2.55.0
> > >
>
next prev parent reply other threads:[~2026-09-01 20:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 15:14 [PATCH 0/5] VRAM health check + CCS fix Matthew Auld
2026-08-28 15:14 ` [PATCH 1/5] drm/xe/migrate: support 4K PTEs for identity map Matthew Auld
2026-08-28 19:46 ` Matthew Brost
2026-09-01 8:48 ` Matthew Auld
2026-09-01 20:07 ` Matthew Brost
2026-08-28 15:14 ` [PATCH 2/5] drm/xe: Don't hand out the flat CCS storage as usable VRAM Matthew Auld
2026-08-28 15:14 ` [PATCH 3/5] drm/xe/vram: report FLAT_CCS base misalignment Matthew Auld
2026-08-28 20:10 ` Matthew Brost
2026-09-01 8:23 ` Matthew Auld
2026-09-01 20:10 ` Matthew Brost [this message]
2026-08-28 15:14 ` [PATCH 4/5] drm/xe: add force option for global invalidation Matthew Auld
2026-09-01 20:29 ` Matthew Brost
2026-08-28 15:14 ` [PATCH 5/5] drm/xe/vram: add early VRAM health check Matthew Auld
2026-08-28 16:13 ` Linus Torvalds
2026-08-28 19:58 ` Matthew Brost
2026-08-28 20:32 ` Linus Torvalds
2026-08-31 20:50 ` Matthew Brost
2026-08-28 16:37 ` Summers, Stuart
2026-09-01 8:33 ` Matthew Auld
2026-09-02 7:45 ` Matthew Brost
2026-09-02 20:34 ` Summers, Stuart
2026-09-03 9:57 ` Matthew Auld
2026-08-28 15:21 ` ✓ CI.KUnit: success for VRAM health check + CCS fix Patchwork
2026-08-28 15:58 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-28 17:06 ` ✓ Xe.CI.FULL: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apcxTIDGDPtBARau@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=stable@kernel.org \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.