Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752142AbcJZFtR (ORCPT ); Wed, 26 Oct 2016 01:49:17 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36607 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751254AbcJZFtN (ORCPT ); Wed, 26 Oct 2016 01:49:13 -0400 Date: Wed, 26 Oct 2016 07:49:09 +0200 From: Daniel Vetter To: "Luis R. Rodriguez" Cc: Dave Airlie , Toshi Kani , Brian Gerst , x86@kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Borislav Petkov , Andy Lutomirski , "H. Peter Anvin" , Denys Vlasenko , dan.j.williams@intel.com, torvalds@linux-foundation.org Subject: Re: [PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1) Message-ID: <20161026054909.wjwq3uy3mlyvlygi@phenom.ffwll.local> Mail-Followup-To: "Luis R. Rodriguez" , Dave Airlie , Toshi Kani , Brian Gerst , x86@kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Borislav Petkov , Andy Lutomirski , "H. Peter Anvin" , Denys Vlasenko , dan.j.williams@intel.com, torvalds@linux-foundation.org References: <1477290706-7696-1-git-send-email-airlied@redhat.com> <1477290706-7696-2-git-send-email-airlied@redhat.com> <20161025173129.GD8651@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161025173129.GD8651@wotan.suse.de> X-Operating-System: Linux phenom 4.6.0-1-amd64 User-Agent: NeoMutt/20161014 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2166 Lines: 43 On Tue, Oct 25, 2016 at 07:31:29PM +0200, Luis R. Rodriguez wrote: > 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. I'll plug the io-mapping stuff again here, and more specifically the userspace pte wrangling stuff we've added in 4.9 to i915_mm.c. Should probably move that one to the core. That way io_mapping takes care of the full reservartion, and allows you to on-demand kmap (for kernel) and write ptes. All nicely fast and all, and for bonus, also nicely encapsulated. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch