From owner-freebsd-arm@freebsd.org Fri Mar 10 17:44:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0FCDD06DD4 for ; Fri, 10 Mar 2017 17:44:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9ACB21ADD for ; Fri, 10 Mar 2017 17:44:53 +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 v2AHijvO096233 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Mar 2017 19:44:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2AHijvO096233 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2AHiivt096232; Fri, 10 Mar 2017 19:44:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 10 Mar 2017 19:44:44 +0200 From: Konstantin Belousov To: Andrew Gierth Cc: Warner Losh , "freebsd-arm@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Message-ID: <20170310174444.GN16105@kib.kiev.ua> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wpbxw3yd.fsf@news-spur.riddles.org.uk> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:44:54 -0000 On Fri, Mar 10, 2017 at 04:10:49PM +0000, Andrew Gierth wrote: > >>>>> "Warner" == Warner Losh writes: > > Warner> I've not had good luck getting it to work. (cortex-a7 is the > Warner> proper type name, btw). It kinda works, but ports are kinda > Warner> wonky. > > >> Well, I can now report that with a local fix for #217611 in place > >> and everything recompiled for cortex-a7, I'm not seeing any > >> wonkiness at all even with a lot of ports in use. > > Warner> Awesome. What's the local fix? Is it in FreeBSD yet? > > No, it's not in FreeBSD yet; I attached it as a patch to the bugzilla > report: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180669&action=diff > > My fix requires breaking the ABI, since the definition of mcontext_t > simply does not have enough space to store all the registers, so I'm > assuming it won't go into stable/11 (though that really needs _some_ > kind of fix, since the bug can be demonstrated with ordinary > floating-point code and no compile options). > > It needs attention from someone with more kernel/arm experience than I > have to see whether I've missed something obvious (or subtle). > > (Maybe I should have filed it under "kern" rather than "arm"?) When x86 AVX support was added, the very same problem existed: the x86 mcontext_t has no space to store AVX registers, and worse, architecture explicitely allowed for future coprocessors to extend the register file further. In other words, even if breaking ABI and adding the storage to mcontext_t for AVX once was decided, the solution would be not sustainable. Also note that extending mcontext_t is very painful, because it is embedded into ucontext_t in the middle, so the change means that whole signal-delivery ABI is broken. In other words, a lot of compat shims is needed, each time. The x86 solution was to put new coprocessor state outside of the mcontext_t and pointing to it. This allowed the grow to happens transparently, mostly controlled by kernel. The getcontextx(3) function was added to not change expectation of (rare) getcontext(3) consumers that ucontext_t is self-contained. One of the important getcontextx(3) users is libthr, and there the internal __getcontextx_size()/__fillcontextx2() interface was added. I am not sure which tier the ARMv6 architecture is. It would seems to migrate to tier1 almost, but the ABI was broken recently with switch to hardfp. If indeed tier1, then ABI breakage is considered imadmissible, and getcontextx() route is probably good enough. The issue I see is that there is no reserved unused fields in mcontext_t on ARM, so probably some trick with not using fpu save area at all for fpu registers might be needed. If applying your patch because the ABI breakage is permitted for ARM, note that besides requiring recompilation, we also loose ability to run older binaries, including jails.