From owner-freebsd-arm@freebsd.org Sun Mar 12 08:17:34 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 70A5DD098D8 for ; Sun, 12 Mar 2017 08:17:34 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 010271222 for ; Sun, 12 Mar 2017 08:17:34 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wr0-x241.google.com with SMTP id u48so16452394wrc.1 for ; Sun, 12 Mar 2017 00:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:cc:reply-to:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=zg+mLZAScbvuHUkohdtCcnrkGiAa2ak09iIwXFKb338=; b=WGadorADMD9Bc1mpfvSHHF4PF1+NQLm2UR8yFpkGwNYhAUugKYAYfI7alYY50ow/IC rfN+ZZMx4cN72sfJItue+9yGDTXwS3nv6R3Sdo96jvmpGQZcPnuV6o8n9zwvSqZMd8ET Na5OUKL4yvHa2AHkrpwxEzYel2u9YkBtW017njo5A6/GuLVvHKKAoc8VQbrMQ3FDFtot ip0a7kLAcohp0YspzSzDekN+5m5UlygWS4UQFEGuoedsGz+KhmGRjlgMP94VlFU3ydON Gkuc98+zOVndHUSR6MCJ7ocN+mZSmdnM1HJO+I7rGo4ctyo8U6ifJ0fn+u1BwuwzeS5+ cfvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:cc:reply-to :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=zg+mLZAScbvuHUkohdtCcnrkGiAa2ak09iIwXFKb338=; b=M1xF6pU30xcZ7sTpFWhx4ujIM6pzUGnwuVMGunvBu4OZdcuVgrkpsTqlrEevY5cGJN vXbOlJVLyde1gDjHB1LvquIgCDoESga8jMbWQkT0mC5gDyY6xbkPv8ZwROZe2nknG5IY 2J7ThuXaBbDDzt9FuP1OvVN6F7SR6udK3gFkQ0U3us+ERFF4QMClHXxB2qLuMDvyJ4xc AQXrUi3rs0ZO7EVAEFYbrhD++JLwBdo+o+46e+jBDl7gbfC7C0tzBQTqmyuzY8Vmh+eN 5Vm+faMwt0+gjzZc7E1bLZO0AMvzv2HWQBh1ElsiNimeibtRbiS4JyPwoJRoxH0ih/yf Qxsg== X-Gm-Message-State: AMke39ltO98RR7OBDLr01SEfYByUNjto2cnhlxRwUIxNmPBV545Lan8VLiz+gduB8ybjTQ== X-Received: by 10.223.163.7 with SMTP id c7mr22561215wrb.17.1489306652525; Sun, 12 Mar 2017 00:17:32 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id y1sm6506338wme.15.2017.03.12.00.17.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Mar 2017 00:17:31 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <20170310174444.GN16105@kib.kiev.ua> To: Konstantin Belousov , Andrew Gierth Cc: "freebsd-arm@freebsd.org" Reply-To: mmel@freebsd.org Message-ID: Date: Sun, 12 Mar 2017 09:17:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170310174444.GN16105@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Sun, 12 Mar 2017 08:17:34 -0000 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 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