Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760106Ab2J2Q47 (ORCPT ); Mon, 29 Oct 2012 12:56:59 -0400 Received: from mail.skyhub.de ([78.46.96.112]:46762 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753360Ab2J2Q45 (ORCPT ); Mon, 29 Oct 2012 12:56:57 -0400 Date: Mon, 29 Oct 2012 17:57:05 +0100 From: Borislav Petkov To: Rik van Riel Cc: Alan Cox , Ingo Molnar , Andi Kleen , Michel Lespinasse , Linus Torvalds , Peter Zijlstra , Andrea Arcangeli , Mel Gorman , Johannes Weiner , Thomas Gleixner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, florian@openwrt.org, Borislav Petkov Subject: Re: [PATCH 2/3] x86,mm: drop TLB flush from ptep_set_access_flags Message-ID: <20121029165705.GA4693@x1.osrc.amd.com> Mail-Followup-To: Borislav Petkov , Rik van Riel , Alan Cox , Ingo Molnar , Andi Kleen , Michel Lespinasse , Linus Torvalds , Peter Zijlstra , Andrea Arcangeli , Mel Gorman , Johannes Weiner , Thomas Gleixner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, florian@openwrt.org, Borislav Petkov References: <508A0A0D.4090001@redhat.com> <508A8D31.9000106@redhat.com> <20121026132601.GC9886@gmail.com> <20121026144502.6e94643e@dull> <20121026221254.7d32c8bf@pyramind.ukuu.org.uk> <508BE459.2080406@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <508BE459.2080406@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1399 Lines: 33 On Sat, Oct 27, 2012 at 09:40:41AM -0400, Rik van Riel wrote: > Borislav, would you happen to know whether AMD (and VIA) CPUs > automatically invalidate TLB entries that cause page faults? If you do > not know, would you happen who to ask? :) Short answer: yes. Long answer (from APM v2, section 5.5.2): Use of Cached Entries When Reporting a Page Fault Exception. On current AMD64 processors, when any type of page fault exception is encountered by the MMU, any cached upper-level entries that lead to the faulting entry are flushed (along with the TLB entry, if already cached) and the table walk is repeated to confirm the page fault using the table entries in memory. This is done because a table entry is allowed to be upgraded (by marking it as present, or by removing its write, execute or supervisor restrictions) without explicitly maintaining TLB coherency. Such an upgrade will be found when the table is re-walked, which resolves the fault. If the fault is confirmed on the re-walk however, a page fault exception is reported, and upper level entries that may have been cached on the re-walk are flushed. HTH. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/