[PATCH] clocksource/drivers/arm_arch_timer: export arch_timer_get_rate

Marc Zyngier maz at kernel.org
Wed Jan 13 05:06:34 EST 2021


On 2021-01-13 09:56, Chanho Park wrote:
> Hi Marc,

[...]

>> Well, you can compare the raw counter values, and do the conversion in 
>> a
>> single place. Also, if your system is correctly configured, you have
>> access to CNTFRQ_EL0, which contains the same thing as
>> arch_timer_get_rate().
> 
> To convert the value in the single place, we may need to use inter-VM
> communication so that it makes quite complex design/implementation for 
> me.
> Regarding CNTFRQ_EL0, I already tried to read it by 
> arch_timer_get_cntfrq
> but I got '0'. It looks like different according to the system.

That's a bug in your firmware that you should consider fixing.
The architecture and the arm64 boot protocol are pretty explicit
that CNTFRQ_EL0 must contain the frequency of the timer, and be
initialised on all CPUs. You are probably using some DT property
to advertise the frequency, which is very much discouraged.

>> 
>> >> So this symbol is probably used by a module *inside* the VMs, and
>> >> Mark's question still stands.
>> >>
>> >
>> > Yes. Actually, we use this timestamp for our internal module which is
>> > not yet upstreamed.
>> 
>> If the module code is not upstream, I don't see the point in exporting
>> this symbol. I suggest you post both as a series so that we can decide
>> whether that is a good idea or not.
> 
> Well, I'm not sure the module can be upstream because it's definitely
> necessary only to analyze a panic in my hypervisor system. Let me find 
> a
> better way to expose this.

If your module doesn't make sense in the upstream kernel, then exporting
the symbol doesn't make much sense either.

         M.
-- 
Jazz is not dead. It just smells funny...



More information about the linux-arm-kernel mailing list