Re: [PATCH v3 3/5] drm/xe/vram: revamp CPU VRAM mapping

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The panic handler incorrectly computes the virtual address for stolen memory framebuffers, silently corrupting normal VRAM instead of drawing the panic screen.
--

commit 122b98d2306bc2a11fb8cd83e0ebcab780bfb24e
Author: Matthew Auld <matthew.auld@intel.com>

drm/xe/vram: revamp CPU VRAM mapping

This commit moves the devm_ioremap_wc() call to vram_region_init(), mapping
VRAM on a per-tile basis restricted to usable_size. It helps catch
out-of-bounds CPU writes by placing a guard page at the end of each per-tile
mapping.

> diff --git a/drivers/gpu/drm/xe/display/xe_panic.c b/drivers/gpu/drm/xe/display/xe_panic.c
> index 12c6fb99015dd..1a6cee25e9d76 100644
> --- a/drivers/gpu/drm/xe/display/xe_panic.c
> +++ b/drivers/gpu/drm/xe/display/xe_panic.c
> @@ -52,7 +52,8 @@ static void xe_panic_page_set_pixel(struct drm_scanout_buffer *sb, unsigned int
>  	if (new_page != panic->page) {
>  		if (xe_bo_is_vram(bo)) {
>  			/* Display is always mapped on root tile */
> -			struct xe_vram_region *vram = xe_bo_device(bo)->mem.vram;
> +			struct xe_vram_region *vram =
> +				xe_device_get_root_tile(xe_bo_device(bo))->mem.vram;
>  
>  			if (panic->page < 0 || new_page < panic->page) {
>  				xe_res_first(bo->ttm.resource, new_page * PAGE_SIZE,

[Severity: High]
This isn't a bug introduced by this patch, but does the panic handler
incorrectly compute the virtual address for stolen memory framebuffers?

When a kernel panic occurs while the active framebuffer is in stolen memory
(XE_PL_STOLEN), xe_bo_is_vram() returns true. The code in
xe_panic_page_set_pixel() then adds panic->res.start (which is an offset
starting at 0 within the stolen region) to vram->mapping (which maps normal
VRAM) slightly below this hunk:

    iosys_map_set_vaddr_iomem(&panic->vmap,
                              vram->mapping + panic->res.start);

This could silently corrupt normal VRAM instead of drawing the panic screen.

While this is a pre-existing issue, restricting vram->mapping to
usable_size in this patch makes it structurally impossible to fix by merely
correcting the offset, as the stolen memory region is explicitly excluded
from the mapping.

Should the panic handler be updated to use xe->mem.stolen_mgr->mapping for
XE_PL_STOLEN buffers?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902124117.918018-7-matthew.auld@intel.com?part=3