From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77873C433F5 for ; Fri, 8 Oct 2021 20:28:43 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2D16160BD3 for ; Fri, 8 Oct 2021 20:28:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2D16160BD3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 734956E101; Fri, 8 Oct 2021 20:28:42 +0000 (UTC) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id B46556E101 for ; Fri, 8 Oct 2021 20:28:41 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10131"; a="225357694" X-IronPort-AV: E=Sophos;i="5.85,358,1624345200"; d="scan'208";a="225357694" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2021 13:28:23 -0700 X-IronPort-AV: E=Sophos;i="5.85,358,1624345200"; d="scan'208";a="525161711" Received: from lenovo-x280.ger.corp.intel.com (HELO [10.249.254.98]) ([10.249.254.98]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2021 13:28:22 -0700 Message-ID: <7abe3906a814e40786da5cd5d45a7b826e262d8e.camel@linux.intel.com> Subject: Re: [PATCH 0/5] drm/vmwgfx: Support module unload and hotunplug From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Zack Rusin , dri-devel@lists.freedesktop.org Cc: Christian =?ISO-8859-1?Q?K=F6nig?= Date: Fri, 08 Oct 2021 22:28:20 +0200 In-Reply-To: <20211008173146.645127-1-zackr@vmware.com> References: <20211008173146.645127-1-zackr@vmware.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 > Cc: Thomas Hellström 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