From owner-freebsd-ppc@freebsd.org Wed May 1 02:01:01 2019 Return-Path: Delivered-To: freebsd-ppc@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 0E16415805F3 for ; Wed, 1 May 2019 02:01:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-33.consmr.mail.ne1.yahoo.com (sonic317-33.consmr.mail.ne1.yahoo.com [66.163.184.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 019F6715A5 for ; Wed, 1 May 2019 02:00:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 3a5aa0sVM1kVVTxSxpiSfqyl_lrcA2hAoWPV6fHhQy0j5QxalCO10WfitHyuz_A ny98prIjLAFlEz4ua.THk1pTQPmrMvAVX_276jITvVOLBCzB_mUoyHUhF0zdvFjlu.tAoJt7fFHx QoOuK9WTlGrOnTfqGvqPUg4BfHSMl4LOmqDXF2uPqWGEoFBLF4Aq_mj4zw4KFViuAKHooXK1Qk4T 0V7vZ2Y0HLPo5dITBR7qDUM9w8fUFxufESaCNFOc0gSWA80fAtdnmDXhGDoavYbnl32hZDoRgndK SYGXAeEPkKyZAOQ3cnUhFl_d5ET30z2wczA_9CdLEOVLKguMzpbHql6X262KOuuVkCvC4_Mq3YZD qZ4ih5g5pkvo7s8w09.zEW2ixy6i7Q_dGueTP51MovdPdtZpHtvqKO7Gqu0IE6vT9X1pVrB5lX2M H0v_zflKsyhXrUsgl5IsUtiXfccWZT0rH_kCTyTDyfDVSGJLsUdKj7852k8hTqWWkmnHj63Cwtk0 aAfaFc.dbSZZRdAEdn5HI0yHWoFPFcP.gEMjA4FUABF6OQwMuKlgeEZM1JG7hF5k8VK0Gn3RKrCP x.hVbZLrrgr.IG4eMHUt3xpO.0MpJXlaJvnl2RH4soseYBmapvtd4OcB5qT2gO4MXngbwJoKBAUS UKPK68DjQppx9Wc5WreSKG4Xz8bH5RICMXYJhP8zQXr0XhlcJPvfuKacAbq8LsiRuRz7IeOlEnIq YaOVK4wKAv1jj3HbcWLqQFfqdgGdSpgUR5I2YJ03QrRboPwYHCLOO3K6icM_2cA6ha18aIy5iWLR MbmeCHcOmm21GjExKzY7iEVpXaF0CiIDZCt_i3pXe3gsbmL3TBE9KfiGP6Lv24z7pd82ilqVqLK0 niIQlVsDpQvkGHgYZr14Rg1J93MK2KVkd_5cGKWbsPUvxa8tfj9cGjhSNt31d2Pu7HeF.zuWDvys Ncq0qtrg0I0mnCPnx52PJqeWBeYM5Pu9HpCAijgvKTYqnOnPG9vJFXJJjPvvudCn9.b0KpCwTxxw Lwweprh7l0SDJJG1Qz2_jz3WXePyZ7t3kC3Xk_D.0kncYluRu2ICWt07ODxrxrMtnbenfG4UKjig q2Ob0hjsMLUT4EDj0HRm3DGxN6F50TyJb4jr88Y712TqMH7y_dqMj.RhBrS7MsdEiP1jb6AELC92 BWLW6tA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Wed, 1 May 2019 02:00:53 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp411.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7148b8f0ac671f9255b6e9120c7bf803; Wed, 01 May 2019 01:50:45 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: moea64_cpu_bootstrap_native slbmte (and such) use: missing context synchronizations (isync's)? Date: Tue, 30 Apr 2019 18:50:43 -0700 References: To: Justin Hibbits , FreeBSD PowerPC ML In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 019F6715A5 X-Spamd-Bar: ++++ X-Spamd-Result: default: False [4.96 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.912,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.28)[0.278,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.99)[0.985,0]; RCVD_IN_DNSWL_NONE(0.00)[44.184.163.66.list.dnswl.org : 127.0.5.0]; IP_SCORE(2.29)[ip: (9.02), ipnet: 66.163.184.0/21(1.39), asn: 36646(1.11), country: US(-0.06)] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 02:01:01 -0000 [Looks like slb_insert_kernel also does not locally have context synchronization around slbmte and I've a question on slbie after slbmte as well.] On 2019-Apr-30, at 17:25, Mark Millard wrote: > First some context that I base this note on . . . >=20 > For Data Access Synchronization: >=20 > slbie, slbia, slbmte all list a context-synchronizing instruction > as "Required Prior" and "Required After". >=20 > For Instruction Access Synchronization: >=20 > slbie, slbia, slbmte all list a context-synchronizing instruction > as "Required After". (There is also a note about not causing an > implicit branch in real space, up to the context synchronization > instruction.) >=20 > Both contexts list the note that says: >=20 > QUOTE > If an slbmte instruction alters the mapping, or associated attributes, = of a currently mapped ESID, the slb- mte must be preceded by an slbie = (or slbia) instruction that invalidates the existing translation. This = applies even if the corresponding entry is no longer in the SLB (the = translation may still be in implementa- tion-specific address = translation lookaside information). No software synchronization is = needed between the slbie and the slbmte, regardless of whether the index = of the SLB entry (if any) containing the current translation is the same = as the SLB index specified by the slbmte. >=20 > No slbie (or slbia) is needed if the slbmte instruction replaces a = valid SLB entry with a mapping of a dif- ferent ESID (e.g., to satisfy = an SLB miss). However, the slbie is needed later if and when the = translation that was contained in the replaced SLB entry is to be = invalidated. > END QUOTE >=20 > In: >=20 > static void > moea64_cpu_bootstrap_native(mmu_t mmup, int ap) > { > . . . > /* > * Install kernel SLB entries > */ >=20 > #ifdef __powerpc64__ > __asm __volatile ("slbia"); > __asm __volatile ("slbmfee %0,%1; slbie %0;" : = "=3Dr"(seg0) : > "r"(0)); >=20 > for (i =3D 0; i < n_slbs; i++) { > if (!(slb[i].slbe & SLBE_VALID)) > continue; >=20 > __asm __volatile ("slbmte %0, %1" :: > "r"(slb[i].slbv), "r"(slb[i].slbe)); > } > #else >=20 > I do not see isync's or such used for this unless > the later else-case in: >=20 > if (cpu_features2 & PPC_FEATURE2_ARCH_3_00) > mtspr(SPR_PTCR, > ((uintptr_t)moea64_part_table & ~DMAP_BASE_ADDRESS) = | > flsl((PART_SIZE >> 12) - 1)); > else > __asm __volatile ("ptesync; mtsdr1 %0; isync" > :: "r"(((uintptr_t)moea64_pteg_table & = ~DMAP_BASE_ADDRESS) > | (uintptr_t)(flsl(moea64_pteg_mask >> = 11)))); > tlbia(); >=20 > is supposed to always be sufficient (for at least after > the slbmte). TLBSYNC(), EIEIO(), and such from tlbia() > do not seem to do isync, unless I missed something. It > looks like Power9 (PPC_FEATURE2_ARCH_3_00) would not get > an isync at all from the range of code I reference. >=20 In: void slb_insert_kernel(uint64_t slbe, uint64_t slbv) { struct slb *slbcache; int i; /* We don't want to be preempted while modifying the kernel map = */ critical_enter(); . . . fillkernslb: KASSERT(i !=3D USER_SLB_SLOT, ("Filling user SLB slot with a kernel mapping")); slbcache[i].slbv =3D slbv; slbcache[i].slbe =3D slbe | (uint64_t)i; /* If it is for this CPU, put it in the SLB right away */ if (pmap_bootstrapped) { /* slbie not required */ __asm __volatile ("slbmte %0, %1" :: "r"(slbcache[i].slbv), "r"(slbcache[i].slbe)); } critical_exit(); } there does not seem to be context synchronizing instructions before or after the slbmte. Also, while a slbie before may not be needed, I'm unclear on the status of a potential slbie needed later: QUOTE the slbie is needed later if and when the translation that was=20 contained in the replaced SLB entry is to be invalidated END QUOTE This slbie-after-slbmte may apply to moea64_cpu_bootstrap_native's use of slbmte as well. moea64_deactivate has just one side of slbie with a synchronizing instruction: void moea64_deactivate(mmu_t mmu, struct thread *td) { pmap_t pm; __asm __volatile("isync; slbie %0" :: "r"(USER_ADDR)); . . . restore_usersrs and restore_kernsrs have a similar status relative to slbia, but with an interrupt context it may be that, for example, the rti covers following context-synchronization sufficiently, in other words, the internal-interrupt-code possibly having no need for such(?). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)