Date: Sun, 12 Mar 2017 09:17:35 +0100 From: Michal Meloun <melounmichal@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com>, Andrew Gierth <andrew@tao11.riddles.org.uk> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Message-ID: <b56aeeb5-f619-3b44-efe7-848f2b98f3da@freebsd.org> In-Reply-To: <20170310174444.GN16105@kib.kiev.ua> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <CANCZdfq4EwH%2B_9FVNai8s6Y-gdTjHJ8dNkJwSrnF%2BSAkdwvYdg@mail.gmail.com> <8737ely05c.fsf@news-spur.riddles.org.uk> <CANCZdfpftVHaPahTOP0vxB-FR%2BKtpqY9JMJr=F2DGifD0fhKMQ@mail.gmail.com> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <20170310174444.GN16105@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
On 10.03.2017 18:44, Konstantin Belousov wrote: > On Fri, Mar 10, 2017 at 04:10:49PM +0000, Andrew Gierth wrote: >>>>>>> "Warner" == Warner Losh <imp@bsdimp.com> 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. ARM is still tier2, but I significantly prefer getcontextx() (or any other, backward compatible) way. Unfortunately, on armv6, the VFP part of kernel <-> userland interaction is broken from day 1. The struct fpreg is also wrong and I'm not sure if or how we can to fix this in compatible way. Michalhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b56aeeb5-f619-3b44-efe7-848f2b98f3da>