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

[Matthew Auld <matthew.auld@intel.com>]

On 02/09/2026 14:12, sashiko-bot@kernel.org wrote:
> 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?

xe_bo_is_vram() will only return true for dgfx + stolen or normal VRAM, 
but we would never want to put frame buffers in the stolen part of VRAM, 
and there is no path that would lead to such a thing. The stolen part of 
VRAM is quite small and is a precious resource for stuff like FBC.

It might be worth checking for this in xe_panic_setup() to make it 
bulletproof though.

> 
> [ ... ]
>