Shared page and related goodies for ARMv7

Konstantin Belousov kostikbel at gmail.com
Tue Sep 29 16:23:22 UTC 2015


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.


More information about the freebsd-arm mailing list