VDSO for arm 32bit

[Gilles Chanteperdrix]

On 05/28/2013 11:23 AM, Will Deacon wrote:

> On Tue, May 28, 2013 at 08:48:33AM +0100, Kumar, Ganesh wrote:
>> Hi Mikel,
>>
>> Kumar, Ganesh writes:
>>  > Hi All,
>>  >
>>  >   I'm working on OMAP5 on greg's LTS kernel 3.4.25, but I see there is  > no support for vdso for arm 32 bit.
>>  > I'm planning to port it to arm 32 bit, is there any work under progress?
>>  > would like to understand why the support for arm 32 bit is not there, any idea?
>>
>>> 32-bit ARM has a "kuser" page at a fixed virtual address, which exports a few critical routines to user-space.  With that, a vdso is mostly redundant.
>>
>>   Thanks for the info, my main idea is to get the gettimeofday exported through the kuser helper,tried looking at the sources
>> but I could not find anything related to that seems done in the mainline kernel tree for arm cortex, am I missing something here?
>> I plan to do that if its not available yet, right now I've started with the kernel doc for the kuser, any pointers further
>> to get the gettimeofday up and running using the kuser, Thanks in advance for your time.
> 
> Be careful here. I had a crack at a gtod implementation for the vectors page
> in the past, but decided to drop it because it quickly became a maintenance
> nightmare. Since the layout of the vectors page must be fixed (as userspace
> jumps to the absolute addresses for the helpers), having large, complicated
> functions (which gtod does become as you quickly start using the stack to
> store all of the shared state with the kernel) means that you can quickly
> back yourself into a corner where the layout of the code cannot change
> without breaking the ABI.
> 
> On top of that, new clock types are added more often than you might think
> (not to mention bug fixes in the implementation itself), and you end up in
> a horrible situation where you'd end up deprecating one implementation and
> adding gettimeofday2 or something equally nasty at a different offset.
> 
> Maybe this can be solved by adding loads of padding between the different
> functions and hoping for the best, but I think a better solution would be to
> try and add something which is actually a vdso but preserves the function
> offsets of the current helpers, thus preserving the ABI. That could then
> replace the vectors page and newer C libraries could make use of the vdso
> functionality. Of course, that's a lot more work and people might have
> objections to the approach.
> 
> Finally, I assume you're only interested in the co-processor backed
> architected timers for this? I know some people were toying with exposing
> memory-mapped timers to userspace, but that really scares me.


Hi,

We have been doing this for some time with Xenomai on ARM. What we do is
that:
- the function to read the clocksource is in the kuser area, at a fixed
address, its precise implementation (depending on the clocksource type)
is copied to the vector page when the clocksource is chosen, it expects
the user-space virtual address of the MMIO register in r0;
- for MMIO registers, the library maps the register with /dev/mem;
- the data to handle gettimeofday (so namely, the contents of the
"struct timekeeper" structure) are copied to the equivalent of a vdso.

Regards.

-- 
                                                                Gilles.