From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752336AbdLLOnq (ORCPT ); Tue, 12 Dec 2017 09:43:46 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:34052 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752141AbdLLOnm (ORCPT ); Tue, 12 Dec 2017 09:43:42 -0500 Date: Tue, 12 Dec 2017 15:43:34 +0100 From: Peter Zijlstra To: Ilia Mirkin Cc: Ingo Molnar , "linux-kernel@vger.kernel.org" , Pekka Paalanen , Lyude , Steven Rostedt , Thomas Gleixner , Karol Herbst , Linus Torvalds , hpa@zytor.com, linux-tip-commits@vger.kernel.org, Karol Herbst Subject: Re: [tip:x86/urgent] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses Message-ID: <20171212144334.slrpfdtptr5nhuhx@hirez.programming.kicks-ass.net> References: <20171127075139.4928-1-kherbst@redhat.com> <20171212134952.2hok6754245qshv3@hirez.programming.kicks-ass.net> <20171212140418.56xld2lxja5rywp7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 12, 2017 at 09:21:10AM -0500, Ilia Mirkin wrote: > The "thing" being mmiotrace, or the "thing" being page-unaligned addresses? mmiotrace > If the former, its primary use-case is for snooping on the NVIDIA > proprietary GPU driver in order to figure out how to drive the > underlying hardware. The driver does ioremap's to get at PCI space, > which mmiotrace "steals" and provides pages without a present bit set, > along with a fault handler. When the fault handler is hit, it > reinstates the faulting page, and single-steps the faulting > instruction At which point you have valid page-tables and another CPU can access that page too. > reading the before/after regs to determine what happened > (doesn't work universally, but enough for instructions used for PCI > MMIO accesses). See mmio-mod.c::pre and post (the latter is called > from the debug handler). And after that you only invalidate the TLBs for the CPU that took the initial fault, leaving possibly stale TLBs on other CPUs. So this 'thing' has huge gaping SMP holes in.