dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Zack Rusin <zackr@vmware.com>, dri-devel@lists.freedesktop.org
Cc: "Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH 0/5] drm/vmwgfx: Support module unload and hotunplug
Date: Fri, 08 Oct 2021 22:28:20 +0200	[thread overview]
Message-ID: <7abe3906a814e40786da5cd5d45a7b826e262d8e.camel@linux.intel.com> (raw)
In-Reply-To: <20211008173146.645127-1-zackr@vmware.com>

On Fri, 2021-10-08 at 13:31 -0400, Zack Rusin wrote:
> This is a largely trivial set that makes vmwgfx support module reload
> and PCI hot-unplug. It also makes IGT's core_hotunplug pass instead
> of kernel oops'ing.
> 
> The one "ugly" change is the "Introduce a new placement for MOB page
> tables". It seems vmwgfx has been violating a TTM assumption that
> TTM_PL_SYSTEM buffers are never fenced for a while. Apart from a
> kernel
> oops on module unload it didn't seem to wreak too much havoc, but we
> shouldn't be abusing TTM. So to solve it we're introducing a new
> placement, which is basically system, but can deal with fenced bo's.
> 
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>

Hi, Zack,

What part of TTM doesn't allow fenced system memory currently? It was
certainly designed to allow that and vmwgfx has been relying on that
since the introduction of MOBs IIRC. Also i915 is currently relying on
that.

/Thomas



  parent reply	other threads:[~2021-10-08 20:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-08 17:31 [PATCH 0/5] drm/vmwgfx: Support module unload and hotunplug Zack Rusin
2021-10-08 17:31 ` [PATCH 1/5] drm/vmwgfx: Remove the deprecated lower mem limit Zack Rusin
2021-10-08 17:31 ` [PATCH 2/5] drm/vmwgfx: Release ttm memory if probe fails Zack Rusin
2021-10-08 17:31 ` [PATCH 3/5] drm/vmwgfx: Fail to initialize on broken configs Zack Rusin
2021-10-08 17:31 ` [PATCH 4/5] drm/vmwgfx: Introduce a new placement for MOB page tables Zack Rusin
2021-10-12 18:57   ` Thomas Hellström
2021-10-13  4:09     ` Zack Rusin
2021-10-08 17:31 ` [PATCH 5/5] drm/vmwgfx: Switch the internal BO's to ttm_bo_type_kernel Zack Rusin
2021-10-08 20:28 ` Thomas Hellström [this message]
2021-10-08 20:40   ` [PATCH 0/5] drm/vmwgfx: Support module unload and hotunplug Zack Rusin
2021-10-08 21:13     ` Thomas Hellström
2021-10-11  8:17       ` Christian König
2021-10-11 12:04         ` Thomas Hellström
2021-10-12  8:27           ` Christian König
2021-10-12  9:10             ` Thomas Hellström
2021-10-12 17:34               ` Zack Rusin
2021-10-13 12:50                 ` Daniel Vetter
2021-10-13 14:56                   ` Zack Rusin

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=7abe3906a814e40786da5cd5d45a7b826e262d8e.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=zackr@vmware.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