From owner-freebsd-ppc@freebsd.org Wed May 1 00:26:05 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 6053115A2C68 for ; Wed, 1 May 2019 00:26:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-21.consmr.mail.ne1.yahoo.com (sonic315-21.consmr.mail.ne1.yahoo.com [66.163.190.147]) (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 BC8C76E8CE for ; Wed, 1 May 2019 00:26:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ymgHLhIVM1k.o.mhB6H_uwBV__ZzkKvIDxeQpRhuEPFErq6gKYIFQugRcrZRJ3L 3g8zRPGgG5FexV5XwivM.1IkyFSIiSJKrq3ME0tX41mDJoh7wZeB22lihl8dEdj7VL.iPskR3AUr zfKyzciqs190poKO9YRjfeDHPLW3lNiCa5BYpbmVIE0Rrps0LKSB0OvqM6rQcHkK0j1dmTlU4Pmi GSSzvo8ktiuo1PwzJiwAQQOQ7khAwyeBNhbUy7gQwPP7v6.YS38YgywjDRNXbNFvxoVscf87GdkP yy.AkYW5CVr7RhDdhZvacFb2t8XTVQjk8tuX3uiyxNKFfFZR4sV0fGtC2Fj7YE8DmpBQ50Czx0LK rZJONo4LtJOvlVyzBlq.PlXSW7RqH0MfWXSHEEWiQWlL06sDzf3EYivATpDbBpXK0AeGtUL3AsTK t_cNQ1hO.9EDPOtYcGI2DX9tvayW_r2eBBQ1q3kKp039xbP4RzmOorAkspZON264mLfYPCet_XhT 69k1faM14y.lJ.WPRe65IXhS9hEjp5RGBI.1TmP2OwPq1JfprkhGDHpzgXIdzmm2MB5852KrdRsV v6G6pgQqshkIWC3628rFQZaVU7Yq3KNnSB0TXu_vR9o1JpTLciiATbi20xgAFCDIKQDueAHd9uGL Img09oRqFODDae5QW.u1ddB1ZBp4G3hMZXiuoftRXUm_zlIGpouVk_dLyxDycusrtKLJACpF6pi_ toAO2YvrKReN6gX1WYofHXUbxyOsJXZXn6sJxgNS25VIxJ.g_ORG4KK3X5sHz97LKWRzwq.Wj5k3 4_cv9Wp2NqBTd17llmjChLum5KktSPnvUoqBbR66zFo6rpgYkFhDJqPcBK1Xhudx7_uimJjpmoac lnB_vsbsFKG4DHDeQS5l39nE1r5gVWcJr3VxMQnBbOOPiWsJ8Ixb4ryKDFzg4rre3xRd7dnoVxh5 M9YHyos1ymHc16TurmFwMYY_ZXt2L2KrcDAFmoQ3x45zfg.BjcfqLbFjq.5CgwRdd4LSnoBmJwfB qSun1GRjfNceBUxQg8L4A34pyJXUOmQyzMzBaOd_4FpXTKERAHHpy_gANtcD5PI01UbhmPpYUxsR M2XHYz12StAL1ftn5z4MeHzFmn4SJBUoX_eBR7SD5ahQMsfgDyzENtJVdPal4iUXzRyqjw7q4wOl n1OJ_.8s- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Wed, 1 May 2019 00:25:57 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp412.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 86511fc8cb2146ef31e613c93b3c4585; Wed, 01 May 2019 00:25:52 +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: moea64_cpu_bootstrap_native slbmte (and such) use: missing context synchronizations (isync's)? Message-Id: Date: Tue, 30 Apr 2019 17:25:51 -0700 To: Justin Hibbits , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: BC8C76E8CE X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.79 / 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.61)[0.609,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.02)[0.024,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.96)[0.964,0]; RCVD_IN_DNSWL_NONE(0.00)[147.190.163.66.list.dnswl.org : 127.0.5.0]; IP_SCORE(1.70)[ip: (6.06), 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 00:26:05 -0000 First some context that I base this note on . . . For Data Access Synchronization: slbie, slbia, slbmte all list a context-synchronizing instruction as "Required Prior" and "Required After". For Instruction Access Synchronization: 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.) Both contexts list the note that says: 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. 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 In: 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 I do not see isync's or such used for this unless the later else-case in: 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(); 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)