On 15/01/2019 14:57, Thomas Gleixner wrote:
> On Tue, 15 Jan 2019, Vincenzo Frascino wrote:
>
>> +/*
>> + * There is one vdso_timestamp object in vvar for each vDSO-accelerated
>> + * clock_id. For high-resolution clocks, this encodes the time
>> + * corresponding to vdso_data.cycle_last. For coarse clocks this encodes
>> + * the actual time.
>> + *
>> + * To be noticed that nsec is left-shifted by vdso_data.shift.
>
> This is only true for highres clocks. For coarse the nsec value is not
> shifted.
>
Agreed, missed part of the comment here. I will fix it in v5.
>> + */
>> +struct vdso_timestamp {
>> + u64 sec;
>> + u64 nsec;
>> +};
>> +
>> +/*
>> + * vdso_data will be accessed by 32 and 64 bit code at the same time
>> + * so we should be careful before modifying this structure.
>> + */
>> +struct vdso_data {
>> + u32 seq; /* Timebase sequence counter */
>> +
>> + s32 clock_mode;
>> + u64 cycle_last; /* Timebase at clocksource init */
>> + u64 mask; /* Clocksource mask (mono = raw) */
>
> mono = raw? This is broken. The VDSO cannot define time different from the
> regular syscall interfaces.
>
On v2 of this series I had the masks for mono and raw separate, but based on
your comment (the core timekeeper has them duplicated purely for access pattern
optimization and simplicity). I unified them. Could you please provide more
details on what should be done in this case?
> Thanks,
>
> tglx
>
--
Regards,
Vincenzo
