All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hellstrom, Thomas" <thomas.hellstrom@intel.com>
To: "Roper, Matthew D" <matthew.d.roper@intel.com>,
	"Bhatia, Aradhya" <aradhya.bhatia@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"Upadhyay, Tejas" <tejas.upadhyay@intel.com>,
	"Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>,
	"De Marchi, Lucas" <lucas.demarchi@intel.com>
Subject: Re: [PATCH 2/2] drm/xe_device: Evict all the VRAM objects during device remove
Date: Fri, 28 Feb 2025 11:21:58 +0000	[thread overview]
Message-ID: <77a5eb08301f7e2de3fab3e9344c94492ddfac13.camel@intel.com> (raw)
In-Reply-To: <20250228065224.320811-3-aradhya.bhatia@intel.com>

On Fri, 2025-02-28 at 06:52 +0000, Aradhya Bhatia wrote:
> Now that xe's migrate subsystem is dev managed, instead of drm
> managed,
> evict all the VRAM objects during the xe device remove.
> 
> The VRAM and TTM resource manager are drm managed, and so they are
> destroyed when all the references to DRM are put. When that happens,
> the
> VRAM and TTM resource managers evict all the BOs before their
> destruction. Since the migrate subsystem will already be finished by
> that point, the resource managers won't be able to evict the BOs
> successfully.
> Change that by preemptively evicting all the VRAM BOs during xe
> device
> remove.
> 
> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_device.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_device.c
> b/drivers/gpu/drm/xe/xe_device.c
> index 9454b51f7ad8..ef293552db6c 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -905,8 +905,22 @@ int xe_device_probe(struct xe_device *xe)
>  
>  void xe_device_remove(struct xe_device *xe)
>  {
> +	int ret;
> +	u32 mem_type;
> +
>  	xe_display_unregister(xe);
>  
> +	for (mem_type = XE_PL_VRAM0; mem_type <= XE_PL_VRAM1;
> ++mem_type) {
> +		struct ttm_resource_manager *man =
> +			ttm_manager_type(&xe->ttm, mem_type);
> +
> +		if (man) {
> +			ret = ttm_resource_manager_evict_all(&xe-
> >ttm, man);
> +			if (ret)
> +				drm_err(&xe->drm, "VRAM evict
> failed! %d\n", ret);
> +		}
> +	}
> +

You probably want to make all this a function in xe_bo.c It also needs
to be called  *after* drm_dev_unplug(). Otherwise the memory can be
brought back in again by a running application.

Finally you'd also want to evict all XE_PL_TT bos, because those are
the ones that have dma maps. Evicting XE_PL_TT to XE_PL_SYSTEM doesn't
do much more than unmapping dma.

/Thomas


>  	drm_dev_unplug(&xe->drm);
>  }
>  


  parent reply	other threads:[~2025-02-28 11:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-28  6:52 [PATCH 0/2] drm/xe: Fix the hotunplug NULL ptr dereference Aradhya Bhatia
2025-02-28  6:52 ` [PATCH 1/2] drm/xe_migrate: Switch from drm to dev managed actions Aradhya Bhatia
2025-02-28  7:01   ` Upadhyay, Tejas
2025-02-28 10:21   ` Matthew Auld
2025-02-28 11:11     ` Hellstrom, Thomas
2025-02-28 12:28       ` Matthew Auld
2025-02-28 12:57         ` Hellstrom, Thomas
2025-02-28 14:47           ` Hellstrom, Thomas
2025-02-28 18:38             ` Matthew Auld
2025-03-10 10:26               ` Aradhya Bhatia
2025-03-03 20:27       ` Lucas De Marchi
2025-02-28  6:52 ` [PATCH 2/2] drm/xe_device: Evict all the VRAM objects during device remove Aradhya Bhatia
2025-02-28  7:18   ` Upadhyay, Tejas
2025-02-28 11:21   ` Hellstrom, Thomas [this message]
2025-02-28  7:30 ` ✓ CI.Patch_applied: success for drm/xe: Fix the hotunplug NULL ptr dereference Patchwork
2025-02-28  7:30 ` ✓ CI.checkpatch: " Patchwork
2025-02-28  7:32 ` ✓ CI.KUnit: " Patchwork
2025-02-28  7:48 ` ✓ CI.Build: " Patchwork
2025-02-28  7:51 ` ✓ CI.Hooks: " Patchwork
2025-02-28  7:52 ` ✓ CI.checksparse: " Patchwork
2025-02-28  8:10 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-28 13:05 ` ✗ Xe.CI.Full: failure " 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=77a5eb08301f7e2de3fab3e9344c94492ddfac13.camel@intel.com \
    --to=thomas.hellstrom@intel.com \
    --cc=aradhya.bhatia@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@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 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.