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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Michal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b56aeeb5-f619-3b44-efe7-848f2b98f3da>