From owner-freebsd-arm@freebsd.org Tue Sep 29 17:12:53 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 D2F6EA0BF15 for ; Tue, 29 Sep 2015 17:12:53 +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 4E1A61121; Tue, 29 Sep 2015 17:12:53 +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 t8THCkR0029726 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Sep 2015 20:12:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t8THCkR0029726 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t8THCkew029725; Tue, 29 Sep 2015 20:12:46 +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 20:12:46 +0300 From: Konstantin Belousov To: Andrew Turner Cc: Ian Lepore , freebsd-arm@freebsd.org Subject: Re: Shared page and related goodies for ARMv7 Message-ID: <20150929171246.GK11284@kib.kiev.ua> References: <20150929132332.GH11284@kib.kiev.ua> <1443539982.1224.433.camel@freebsd.org> <20150929162312.GJ11284@kib.kiev.ua> <20150929175422.417baf94@bender.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150929175422.417baf94@bender.Home> 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 17:12:53 -0000 On Tue, Sep 29, 2015 at 05:54:22PM +0100, Andrew Turner wrote: > On Tue, 29 Sep 2015 19:23:12 +0300 > Konstantin Belousov wrote: > > > On Tue, Sep 29, 2015 at 09:19:42AM -0600, Ian Lepore wrote: > > > 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 an optional feature on ARMv7, we only build it for Exynos 5, > Raspberry Pi 2, and QEMU virt. > > How will it work on hardware that lacks the generic timer? Will it > always try and use this hardware, even if it's missing, or do we need > to tell userland what to use, with a fallback to a syscall? The AT_TIMEKEEP aux vector is provided by kernel. It points to the struct vdso_timekeep (see sys/vdso.h), which contains tk_ver and tk_enabled fields. The tk_ver member defines the version for layout of the struct vdso_timekeep, and tk_enabled is boolean which indicates should the user-space gettimeofday() mechanism be used. The tk_enabled member is never set to true for non generic timer timecounter in the patch. If the hardware is compatible, operator can still manually control use of the syscall vs. usermode time with sysctl kern.timecounter.fast_gettime. The struct vdso_timehands has the th_algo member, which is intended to communicate the actual algorithm to calculate the time. Idea of algorithm includes both kind of hardware used and interpretation of the VDSO_TIMEHANDS_MD members, if required by algorithm. This was intended to, eg. select between different hardware like RDTSC or HPET on x86.