From owner-svn-src-all@freebsd.org  Thu Nov 28 13:52:38 2019
Return-Path: <owner-svn-src-all@freebsd.org>
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 <kostikbel@gmail.com>
To: Andrew Turner <andrew@fubar.geek.nz>
Cc: meloun.michal@gmail.com, Alan Cox <alc@FreeBSD.org>,
 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>
 <df22055b-2f80-2f9f-2b45-f66281435846@gmail.com>
 <EBA9203E-17DF-455D-A491-EB4AEE0E37DF@fubar.geek.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <EBA9203E-17DF-455D-A491-EB4AEE0E37DF@fubar.geek.nz>
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 &quot;
 user&quot; and &quot; projects&quot; \)" <svn-src-all.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-all>,
 <mailto:svn-src-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all/>
List-Post: <mailto:svn-src-all@freebsd.org>
List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-all>,
 <mailto:svn-src-all-request@freebsd.org?subject=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 <meloun.michal@gmail.com> 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.