From owner-svn-src-all@FreeBSD.ORG Tue Jul 29 13:11:38 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80EEF890; Tue, 29 Jul 2014 13:11:38 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6DEBD2D3A; Tue, 29 Jul 2014 13:11:38 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id s6TDBcLw070685; Tue, 29 Jul 2014 13:11:38 GMT (envelope-from marius@svn.freebsd.org) Received: (from marius@localhost) by svn.freebsd.org (8.14.9/8.14.9/Submit) id s6TDBcnm070684; Tue, 29 Jul 2014 13:11:38 GMT (envelope-from marius@svn.freebsd.org) Message-Id: <201407291311.s6TDBcnm070684@svn.freebsd.org> From: Marius Strobl Date: Tue, 29 Jul 2014 13:11:38 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org Subject: svn commit: r269238 - stable/10/sys/amd64/amd64 X-SVN-Group: stable-10 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 13:11:38 -0000 Author: marius Date: Tue Jul 29 13:11:37 2014 New Revision: 269238 URL: http://svnweb.freebsd.org/changeset/base/269238 Log: MFC: r269051 Copying pages via temporary mappings in the !DMAP case of pmap_copy_pages() involves updating the corresponding page tables followed by accesses to the pages in question. This sequence is subject to the situation exactly described in the "AMD64 Architecture Programmer's Manual Volume 2: System Programming" rev. 3.23, "7.3.1 Special Coherency Considerations" [1, p. 171 f.]. Therefore, issuing the INVLPG right after modifying the PTE bits is crucial (see also r269050, MFCed to stable/10 in r269235). For the amd64 PMAP code, the order of instructions was already correct. The above fact still is worth documenting, though. 1: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/24593_APM_v21.pdf Reviewed by: alc Sponsored by: Bally Wulff Games & Entertainment GmbH Modified: stable/10/sys/amd64/amd64/pmap.c Directory Properties: stable/10/ (props changed) Modified: stable/10/sys/amd64/amd64/pmap.c ============================================================================== --- stable/10/sys/amd64/amd64/pmap.c Tue Jul 29 13:08:56 2014 (r269237) +++ stable/10/sys/amd64/amd64/pmap.c Tue Jul 29 13:11:37 2014 (r269238) @@ -4984,6 +4984,14 @@ pmap_copy_pages(vm_page_t ma[], vm_offse int cnt; boolean_t pinned; + /* + * NB: The sequence of updating a page table followed by accesses + * to the corresponding pages used in the !DMAP case is subject to + * the situation described in the "AMD64 Architecture Programmer's + * Manual Volume 2: System Programming" rev. 3.23, "7.3.1 Special + * Coherency Considerations". Therefore, issuing the INVLPG right + * after modifying the PTE bits is crucial. + */ pinned = FALSE; while (xfersize > 0) { a_pg_offset = a_offset & PAGE_MASK;