Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Vivi, Rodrigo" <rodrigo.vivi@intel.com>
To: "Upadhyay, Tejas" <tejas.upadhyay@intel.com>,
	"Tauro, Riana" <riana.tauro@intel.com>,
	"aravind.iddamsetty@linux.intel.com"
	<aravind.iddamsetty@linux.intel.com>,
	"Jadav, Raag" <raag.jadav@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"Brost,  Matthew" <matthew.brost@intel.com>,
	"Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>,
	"Auld, Matthew" <matthew.auld@intel.com>
Subject: Re: [RFC PATCH 6/6] [DO NOT REVIEW]]drm/xe/cri: Add sysfs interface for bad gpu vram pages
Date: Fri, 20 Feb 2026 14:52:44 +0000	[thread overview]
Message-ID: <943a10ec67eb0de1d050bb90eda30f0826587b1b.camel@intel.com> (raw)
In-Reply-To: <0ba5c665-e37b-41b5-9692-9f02f30682de@linux.intel.com>

On Fri, 2026-02-20 at 16:48 +0530, Aravind Iddamsetty wrote:
> 
> On 18-02-2026 06:07, Rodrigo Vivi wrote:
> > On Fri, Feb 13, 2026 at 02:55:59PM +0530, Tejas Upadhyay wrote:
> > > Starting CRI, Include a sysfs interface designed to expose
> > > information
> > > about bad VRAM pages—those identified as having hardware faults
> > > (e.g., ECC errors). This interface allows userspace tools and
> > > administrators to monitor the health of the GPU's local memory
> > > and
> > > track the status of page retirement.To get details on bad gpu
> > > vram
> > > pages can be found under /sys/bus/pci/devices/bdf/vram_bad_pages.
> > > 
> > > Where The format is, pfn : gpu page size : flags
> > > 
> > > flags:
> > > R: reserved, this gpu page is reserved.
> > > P: pending for reserve, this gpu page is marked as bad, will be
> > > reserved in next window of page_reserve.
> > > F: unable to reserve. this gpu page can’t be reserved due to some
> > > reasons.
> > > 
> > > For example if you read using cat
> > > /sys/bus/pci/devices/bdf/vram_bad_pages,
> > > 0x00000000 : 0x00001000 : R
> > > 0x00001234 : 0x00001000 : P
> > Riana, Raag, Aravind, a good new use case for the drm-ras no?!
> > Thoughts?
> 
> In general the feature can be supported via drm-ras framework, but is
> the motivation to move all error related info to drm-ras, also any
> gpu
> hang data, health etc..,

No, the motivation is not to move everything there.
I was thinking on the lines of avoiding sysfs. But well, it is only
one sysfs and I don't believe we would need any notification upon
new pages marked as bad, or do we?

If we need notifications then sysfs is bad choice and netlink could
provide info and notification in a single place.

> 
> Thanks,
> Aravind.
> > 
> > > Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/xe_device_sysfs.c |  2 +
> > >  drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 78
> > > ++++++++++++++++++++++++++++
> > >  drivers/gpu/drm/xe/xe_ttm_vram_mgr.h |  1 +
> > >  3 files changed, 81 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_device_sysfs.c
> > > b/drivers/gpu/drm/xe/xe_device_sysfs.c
> > > index a73e0e957cb0..e6a017601428 100644
> > > --- a/drivers/gpu/drm/xe/xe_device_sysfs.c
> > > +++ b/drivers/gpu/drm/xe/xe_device_sysfs.c
> > > @@ -14,6 +14,7 @@
> > >  #include "xe_pcode_api.h"
> > >  #include "xe_pcode.h"
> > >  #include "xe_pm.h"
> > > +#include "xe_ttm_vram_mgr.h"
> > >  
> > >  /**
> > >   * DOC: Xe device sysfs
> > > @@ -284,6 +285,7 @@ int xe_device_sysfs_init(struct xe_device
> > > *xe)
> > >  		if (ret)
> > >  			return ret;
> > >  	}
> > > +	xe_ttm_vram_sysfs_init(xe);
> > >  
> > >  	return 0;
> > >  }
> > > diff --git a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> > > b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> > > index cb3394000e83..c6a81ccaa9d2 100644
> > > --- a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> > > +++ b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> > > @@ -744,3 +744,81 @@ int xe_ttm_tbo_handle_addr_fault(struct
> > > xe_tile *tile, unsigned long addr)
> > >  	return ret;
> > >  }
> > >  EXPORT_SYMBOL(xe_ttm_tbo_handle_addr_fault);
> > > +
> > > +static void xe_ttm_vram_dump_bad_pages_info(char *buf, struct
> > > xe_ttm_vram_mgr *mgr)
> > > +{
> > > +	const unsigned int element_size = sizeof("0xabcdabcd :
> > > 0x12345678 : R\n") - 1;
> > > +	struct xe_ttm_offline_resource *pos, *n;
> > > +	struct drm_buddy_block *block;
> > > +	ssize_t s = 0;
> > > +
> > > +	mutex_lock(&mgr->lock);
> > > +	list_for_each_entry_safe(pos, n, &mgr->offlined_pages,
> > > offlined_link) {
> > > +		block = list_first_entry(&pos->blocks,
> > > +					 struct drm_buddy_block,
> > > +					 link);
> > > +		s += scnprintf(&buf[s], element_size + 1,
> > > +			       "0x%08llx : 0x%08llx : %1s\n",
> > > +			       drm_buddy_block_offset(block) >>
> > > PAGE_SHIFT,
> > > +			       drm_buddy_block_size(&mgr->mm,
> > > block),
> > > +			       "R");
> > > +	}
> > > +	list_for_each_entry_safe(pos, n, &mgr->queued_pages,
> > > queued_link) {
> > > +		block = list_first_entry(&pos->blocks,
> > > +					 struct drm_buddy_block,
> > > +					 link);
> > > +		s += scnprintf(&buf[s], element_size + 1,
> > > +			       "0x%08llx : 0x%08llx : %1s\n",
> > > +			       drm_buddy_block_offset(block) >>
> > > PAGE_SHIFT,
> > > +			       drm_buddy_block_size(&mgr->mm,
> > > block),
> > > +			       "P");
> > > +	}
> > > +	mutex_unlock(&mgr->lock);
> > > +}
> > > +
> > > +static ssize_t vram_bad_pages_show(struct device *dev, struct
> > > device_attribute *attr, char *buf)
> > > +{
> > > +	struct pci_dev *pdev = to_pci_dev(dev);
> > > +	struct xe_device *xe = pdev_to_xe_device(pdev);
> > > +	struct ttm_resource_manager *man;
> > > +	u8 mem_type = XE_PL_VRAM1;
> > > +
> > > +	do {
> > > +		man = ttm_manager_type(&xe->ttm, mem_type);
> > > +		struct xe_ttm_vram_mgr *mgr =
> > > to_xe_ttm_vram_mgr(man);
> > > +
> > > +		if (man)
> > > +			xe_ttm_vram_dump_bad_pages_info(buf,
> > > mgr);
> > > +		--mem_type;
> > > +	} while (mem_type >= XE_PL_VRAM0);
> > > +
> > > +	return sysfs_emit(buf, "%s\n", buf);
> > > +}
> > > +static DEVICE_ATTR_RO(vram_bad_pages);
> > > +
> > > +static void xe_ttm_vram_sysfs_fini(void *arg)
> > > +{
> > > +	struct xe_device *xe = arg;
> > > +
> > > +	device_remove_file(xe->drm.dev,
> > > &dev_attr_vram_bad_pages);
> > > +}
> > > +
> > > +/**
> > > + * xe_ttm_vram_sysfs_init - Initialize vram sysfs component
> > > + * @tile: Xe Tile object
> > > + *
> > > + * It needs to be initialized after the main tile component is
> > > ready
> > > + *
> > > + * Returns: 0 on success, negative error code on error.
> > > + */
> > > +int xe_ttm_vram_sysfs_init(struct xe_device *xe)
> > > +{
> > > +	int err;
> > > +
> > > +	err = device_create_file(xe->drm.dev,
> > > &dev_attr_vram_bad_pages);
> > > +	if (err)
> > > +		return 0;
> > > +
> > > +	return devm_add_action_or_reset(xe->drm.dev,
> > > xe_ttm_vram_sysfs_fini, xe);
> > > +}
> > > +EXPORT_SYMBOL(xe_ttm_vram_sysfs_init);
> > > diff --git a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.h
> > > b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.h
> > > index 5872e8b48779..6e69140c0be8 100644
> > > --- a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.h
> > > +++ b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.h
> > > @@ -34,6 +34,7 @@ void xe_ttm_vram_get_used(struct
> > > ttm_resource_manager *man,
> > >  int xe_ttm_tbo_handle_addr_fault(struct xe_tile *tile, unsigned
> > > long addr);
> > >  void xe_ttm_vram_dump_allocated_blocks(struct drm_device *dev,
> > > struct drm_buddy *mm,
> > >  				       struct drm_printer *p);
> > > +int xe_ttm_vram_sysfs_init(struct xe_device *xe);
> > >  static inline struct xe_ttm_vram_mgr_resource *
> > >  to_xe_ttm_vram_mgr_resource(struct ttm_resource *res)
> > >  {
> > > -- 
> > > 2.52.0
> > > 

  reply	other threads:[~2026-02-20 14:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-13  9:25 [RFC PATCH 0/6] Add memory page offlining support Tejas Upadhyay
2026-02-13  9:25 ` [RFC PATCH 1/6] drm/xe/svm: Use res_to_mem_region Tejas Upadhyay
2026-02-24  2:16   ` Matthew Brost
2026-02-13  9:25 ` [RFC PATCH 2/6] drm/xe: Implement VRAM object tracking ability using physical address Tejas Upadhyay
2026-02-13  9:25 ` [RFC PATCH 3/6] drm/xe: Handle physical memory address error Tejas Upadhyay
2026-02-13  9:25 ` [RFC PATCH 4/6] [DO NOT REVIEW]drm/xe/cri: Add debugfs to inject faulty vram address Tejas Upadhyay
2026-02-13  9:25 ` [RFC PATCH 5/6] drm/xe: Add routine to dump allocated VRAM blocks Tejas Upadhyay
2026-02-13  9:25 ` [RFC PATCH 6/6] [DO NOT REVIEW]]drm/xe/cri: Add sysfs interface for bad gpu vram pages Tejas Upadhyay
2026-02-18  0:37   ` Rodrigo Vivi
2026-02-20 11:18     ` Aravind Iddamsetty
2026-02-20 14:52       ` Vivi, Rodrigo [this message]
2026-02-22  5:32         ` Aravind Iddamsetty
2026-02-23 21:26           ` Rodrigo Vivi

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=943a10ec67eb0de1d050bb90eda30f0826587b1b.camel@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=aravind.iddamsetty@linux.intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=raag.jadav@intel.com \
    --cc=riana.tauro@intel.com \
    --cc=tejas.upadhyay@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox