Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965976AbcJYRbg (ORCPT ); Tue, 25 Oct 2016 13:31:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:49555 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933600AbcJYRbe (ORCPT ); Tue, 25 Oct 2016 13:31:34 -0400 Date: Tue, 25 Oct 2016 19:31:29 +0200 From: "Luis R. Rodriguez" To: Dave Airlie Cc: torvalds@linux-foundation.org, dan.j.williams@intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Toshi Kani , Borislav Petkov , "H. Peter Anvin" , Andy Lutomirski , Denys Vlasenko , Brian Gerst Subject: Re: [PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1) Message-ID: <20161025173129.GD8651@wotan.suse.de> References: <1477290706-7696-1-git-send-email-airlied@redhat.com> <1477290706-7696-2-git-send-email-airlied@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1477290706-7696-2-git-send-email-airlied@redhat.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1600 Lines: 33 On Mon, Oct 24, 2016 at 04:31:45PM +1000, Dave Airlie wrote: > A recent change to the mm code in: > 87744ab3832b83ba71b931f86f9cfdb000d07da5 > mm: fix cache mode tracking in vm_insert_mixed() > > started enforcing checking the memory type against the registered list for > amixed pfn insertion mappings. It happens that the drm drivers for a number > of gpus relied on this being broken. Currently the driver only inserted > VRAM mappings into the tracking table when they came from the kernel, > and userspace mappings never landed in the table. This led to a regression > where all the mapping end up as UC instead of WC now. Eek. > I've considered a number of solutions but since this needs to be fixed > in fixes and not next, and some of the solutions were going to introduce > overhead that hadn't been there before I didn't consider them viable at > this stage. These mainly concerned hooking into the TTM io reserve APIs, > but these API have a bunch of fast paths I didn't want to unwind to add > this to. > > The solution I've decided on is to add a new API like the arch_phys_wc > APIs (these would have worked but wc_del didn't take a range), and > use them from the drivers to add a WC compatible mapping to the table > for all VRAM on those GPUs. This means we can then create userspace > mapping that won't get degraded to UC. Is anything on a driver to be able to tell when this is actually needed ? How will driver developers know? Can you add a bit of documentation to the API? If its transitive towards a secondary solution indicating so would help driver developers. Luis