From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com ([192.55.52.88]:16660 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750758AbeEKO21 (ORCPT ); Fri, 11 May 2018 10:28:27 -0400 Subject: Re: [PATCH] drm/i915/oa: Disable OA on Haswell To: Chris Wilson , intel-gfx@lists.freedesktop.org Cc: Matthew Auld , Joonas Lahtinen , Rodrigo Vivi , Jani Nikula , stable@vger.kernel.org References: <20180511135602.13071-1-chris@chris-wilson.co.uk> <152604831741.14639.14005844103011393462@mail.alporthouse.com> From: Lionel Landwerlin Message-ID: <467008df-d2c7-90d0-64ff-0b913892a3ed@intel.com> Date: Fri, 11 May 2018 15:28:24 +0100 MIME-Version: 1.0 In-Reply-To: <152604831741.14639.14005844103011393462@mail.alporthouse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: stable-owner@vger.kernel.org List-ID: On 11/05/18 15:18, Chris Wilson wrote: > Quoting Lionel Landwerlin (2018-05-11 15:14:13) >> My understanding of the virtual memory addressing from the GPU is limited... >> But how can the GPU poke at the kernel's allocated data? >> I thought we mapped into the GPU's address space only what is allocated >> through gem. > Correct. The HW should only be accessing the pages through the GTT and > the GTT should only contain known pages (or a pointer to the scratch > page). There is maybe a hole where we are freeing the memory before > the HW has finished using it (still writing through stale TLB and > whatnot even though the system has reallocated the pages), but other > than that quite, quite scary. Hence this awooga. > -Chris > Oh right... So this patch is a backup if you previous one won't fix the issue we see on CI? - Lionel