Shared page and related goodies for ARMv7

[Michal Meloun]

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