From owner-freebsd-arm@freebsd.org Wed Sep 30 13:13:44 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 002ECA0CA1B for ; Wed, 30 Sep 2015 13:13:44 +0000 (UTC) (envelope-from meloun@miracle.cz) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3AC1220 for ; Wed, 30 Sep 2015 13:13:42 +0000 (UTC) (envelope-from meloun@miracle.cz) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 275B4ACAD36 for ; Wed, 30 Sep 2015 15:05:12 +0200 (CEST) From: Michal Meloun Subject: Re: Shared page and related goodies for ARMv7 To: freebsd-arm@freebsd.org References: <20150929132332.GH11284@kib.kiev.ua> <1443539982.1224.433.camel@freebsd.org> <20150929162312.GJ11284@kib.kiev.ua> Organization: Miracle Group Message-ID: <560BDE08.4010405@miracle.cz> Date: Wed, 30 Sep 2015 15:05:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150929162312.GJ11284@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Wed, 30 Sep 2015 15:05:12 +0200 (CEST) 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: Wed, 30 Sep 2015 13:13:44 -0000 Dne 29.09.2015 v 18:23 Konstantin Belousov napsal(a): > 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 like to have not-executable stack and signal trampoline on shared page, definitively. Can you, please, move timer related code to another patch? Ian, do you have any objection to this part? I only want to clarify "usage" rules for multiple mappings of physical page/range: - all aliases must use same memory type - all aliases must use same cache attributes in other words, only privileges can vary. Also on ARM, devices must be mapped using "device" memory type. >> >> 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. I don't thing that infecting user mode binaries by underlining hardware details is best choice. Moreover, I know at least 7 different timers implementation on ARMv6 and ARMv7. So we must be very flexible in this area. For example, we can do that like in signal trampoline case. A timer driver can inject its own user mode code to shared page for reading timecounter value. With fallback to syscall, of course. Michal Meloun