From owner-svn-src-stable@freebsd.org Fri Jun 22 10:44:34 2018 Return-Path: Delivered-To: svn-src-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 336C21016BBD; Fri, 22 Jun 2018 10:44:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA16B8ACF7; Fri, 22 Jun 2018 10:44:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9CE9E1FA47; Fri, 22 Jun 2018 10:44:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w5MAiXFF074968; Fri, 22 Jun 2018 10:44:33 GMT (envelope-from avg@FreeBSD.org) Received: (from avg@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w5MAiX16074967; Fri, 22 Jun 2018 10:44:33 GMT (envelope-from avg@FreeBSD.org) Message-Id: <201806221044.w5MAiX16074967@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: avg set sender to avg@FreeBSD.org using -f From: Andriy Gapon Date: Fri, 22 Jun 2018 10:44:33 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org Subject: svn commit: r335555 - stable/11/sys/x86/x86 X-SVN-Group: stable-11 X-SVN-Commit-Author: avg X-SVN-Commit-Paths: stable/11/sys/x86/x86 X-SVN-Commit-Revision: 335555 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 10:44:34 -0000 Author: avg Date: Fri Jun 22 10:44:33 2018 New Revision: 335555 URL: https://svnweb.freebsd.org/changeset/base/335555 Log: MFC r333321,r333707: x86 cpususpend_handler: call wbinvd after setting suspend state bits Without a subsequent wbinvd the changes to suspended_cpus (and resuming_cpus) can be lost at least on AMD systems that use MOESI cache coherency protocol. That can happen because one of APs ends up as an Owner of the corresponding cache line(s) and the changes may never reach the main memory before the AP is reset. This change fixed suspend to RAM a previously broken AMD-based system. Modified: stable/11/sys/x86/x86/mp_x86.c Directory Properties: stable/11/ (props changed) Modified: stable/11/sys/x86/x86/mp_x86.c ============================================================================== --- stable/11/sys/x86/x86/mp_x86.c Fri Jun 22 10:39:22 2018 (r335554) +++ stable/11/sys/x86/x86/mp_x86.c Fri Jun 22 10:44:33 2018 (r335555) @@ -1317,15 +1317,33 @@ cpususpend_handler(void) #else npxsuspend(susppcbs[cpu]->sp_fpususpend); #endif - wbinvd(); - CPU_SET_ATOMIC(cpu, &suspended_cpus); /* - * Hack for xen, which does not use resumectx() so never - * uses the next clause: set resuming_cpus early so that - * resume_cpus() can wait on the same bitmap for acpi and - * xen. resuming_cpus now means eventually_resumable_cpus. + * suspended_cpus is cleared shortly after each AP is restarted + * by a Startup IPI, so that the BSP can proceed to restarting + * the next AP. + * + * resuming_cpus gets cleared when the AP completes + * initialization after having been released by the BSP. + * resuming_cpus is probably not the best name for the + * variable, because it is actually a set of processors that + * haven't resumed yet and haven't necessarily started resuming. + * + * Note that suspended_cpus is meaningful only for ACPI suspend + * as it's not really used for Xen suspend since the APs are + * automatically restored to the running state and the correct + * context. For the same reason resumectx is never called in + * that case. */ + CPU_SET_ATOMIC(cpu, &suspended_cpus); CPU_SET_ATOMIC(cpu, &resuming_cpus); + + /* + * Invalidate the cache after setting the global status bits. + * The last AP to set its bit may end up being an Owner of the + * corresponding cache line in MOESI protocol. The AP may be + * stopped before the cache line is written to the main memory. + */ + wbinvd(); } else { #ifdef __amd64__ fpuresume(susppcbs[cpu]->sp_fpususpend); @@ -1337,7 +1355,7 @@ cpususpend_handler(void) PCPU_SET(switchtime, 0); PCPU_SET(switchticks, ticks); - /* Indicate that we are resuming */ + /* Indicate that we have restarted and restored the context. */ CPU_CLR_ATOMIC(cpu, &suspended_cpus); }