From owner-svn-src-all@freebsd.org Thu Nov 28 13:52:38 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 13F9C1AA771; Thu, 28 Nov 2019 13:52:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47Nzbm25wLz4brZ; Thu, 28 Nov 2019 13:52:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id xASDqQsp022188 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 28 Nov 2019 15:52:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua xASDqQsp022188 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id xASDqQdV022187; Thu, 28 Nov 2019 15:52:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Nov 2019 15:52:26 +0200 From: Konstantin Belousov To: Andrew Turner Cc: meloun.michal@gmail.com, Alan Cox , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r355145 - head/sys/arm64/arm64 Message-ID: <20191128135226.GR10580@kib.kiev.ua> References: <201911272033.xARKXowX014908@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 47Nzbm25wLz4brZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-0.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[6]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; IP_SCORE(0.00)[ip: (-2.76), ipnet: 2001:470::/32(-4.64), asn: 6939(-3.52), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEMAIL_CC(0.00)[gmail.com]; SUSPICIOUS_RECIPS(1.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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: Thu, 28 Nov 2019 13:52:38 -0000 On Thu, Nov 28, 2019 at 09:17:15AM +0000, Andrew Turner wrote: > > > > On 28 Nov 2019, at 08:48, Michal Meloun wrote: > > > > > > > > On 27.11.2019 21:33, Alan Cox wrote: > >> Author: alc > >> Date: Wed Nov 27 20:33:49 2019 > >> New Revision: 355145 > >> URL: https://svnweb.freebsd.org/changeset/base/355145 > >> > >> Log: > >> There is no reason why we need to pin the underlying thread to its current > >> processor in pmap_invalidate_{all,page,range}(). These functions are using > >> an instruction that broadcasts the TLB invalidation to every processor, so > >> even if a thread migrates in the middle of one of these functions every > >> processor will still perform the required TLB invalidations. > > I think this is not the right assumption. The problem is not in TLB > > operations themselves, but in following 'dsb' and / or 'isb'. 'dsb' > > ensures that all TLB operation transmitted by the local CPU is performed > > and visible to other observers. But it does nothing with TLBs emitted by > > other CPUs. > > For example, if a given thread is rescheduled after all TLB operations > > but before 'dsb' or 'isb' is performed, then the requested > > synchronization does not occur at all. > > The tibi instructions need a context synchronisation point. One option is the dsb & isb instructions, another is an exception entry. > > For a thread to be rescheduled it requires the timer interrupt to fire. As an exception entry is a context synchronisation point and an interrupt will cause an exception entry there will be such a point after the the tibi instruction. > D5.10.2. TLB maintenance instructions, 'Ordering and completion of TLB maintenance instructions' states that DSB on the PE that issued TLBI is required. It does not state that arbitrary even causing SynchronizeContext() is enough. Also I was not able to find any explanation of SynchronizeContext(). Curiously, on IA32 exceptions are not specified to issue a serialization point, although rumors say that on all produced microarchitectures they are.