From owner-freebsd-arm@freebsd.org Tue Sep 29 16:23:22 2015 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 2FA44A0CB9E for ; Tue, 29 Sep 2015 16:23:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CAE271E7B; Tue, 29 Sep 2015 16:23:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t8TGNCVr017657 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Sep 2015 19:23:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t8TGNCVr017657 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t8TGNCKX017656; Tue, 29 Sep 2015 19:23:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 29 Sep 2015 19:23:12 +0300 From: Konstantin Belousov To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: Shared page and related goodies for ARMv7 Message-ID: <20150929162312.GJ11284@kib.kiev.ua> References: <20150929132332.GH11284@kib.kiev.ua> <1443539982.1224.433.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1443539982.1224.433.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 16:23:22 -0000 On Tue, Sep 29, 2015 at 09:19:42AM -0600, Ian Lepore wrote: > I can't do anything with an inline email patch (my mail client destroys > whitespace). Can you send it as an attachment, or put it somewhere on > freefall or something please? I just committed the .note.GNU-stack bits, reviewed by andrew. This reduces the noise in the patch, the rest is available at https://people.freebsd.org/~kib/misc/arm_sharedpage.1.patch > > There is no difference between armv6 and armv7 in our world. The only > armv6 chip we support is the one used in the original rpi and it has a > 16K 4-way L1 cache which means the page coloring issue disappears and we > can treat it the same as an armv7 chip (different cache ops, but the > caches behave the same). Olivier just told me the same, I already changed the elf_machdep.c patch to enable shared page for ARMv6 and later. > > I just skimmed through the patch quickly and the main thing that jumps > out at me is that what you've done works only on rpi2 and aarch64, > because those are the only platforms that support that timer hardware. > (That means I can't test it, but once I get your patch in a usable form > I can have a shot at implementations for other timers). Cortex A7/A15 and whole ARMv8 is not too bad set of machines for fast gettimeofday() IMO, at least for the first try. I am willing to adjust both approach and code it for wider usefulness. > > It's not clear to me that this scheme can even work on most armv7 > hardware because of the timer hardware involved. I think it would mean > giving userland read access to a whole page worth of IO space and in > some cases there are registers in that range where reads have side > effects whose consequences could be dire (such as pending-interrupt > registers). Yes, if timer counter is on the page shared with other registers, which read side effects are not safe, it cannot be used. But I do not see how such hardware could be useful for any syscall-less implementation of gettimeofday(), except for very imprecise one, where counter is written to the shared page on timer interrupt. I do not think that we want such hack done. On x86, HPET timers have relatively sane design, the registers page can be exported to userspace r/o without consequences. Exporting HPET to userspace even could be useful on Core2 (old) machines where RDTSC is unusable. HPET could be made a test bed for this kind of hardware, but the interest is low and I did not coded neccessary infrastructure as result.