Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Sep 2015 15:05:12 +0200
From:      Michal Meloun <meloun@miracle.cz>
To:        freebsd-arm@freebsd.org
Subject:   Re: Shared page and related goodies for ARMv7
Message-ID:  <560BDE08.4010405@miracle.cz>
In-Reply-To: <20150929162312.GJ11284@kib.kiev.ua>
References:  <20150929132332.GH11284@kib.kiev.ua> <1443539982.1224.433.camel@freebsd.org> <20150929162312.GJ11284@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?560BDE08.4010405>