Re: [PATCH 2/5] kvmtrace: make cycle calculation architecture aware

[Hollis Blanchard <hollisb@us.ibm.com>]

On Mon, 2008-07-07 at 15:56 +0200, ehrhardt@linux.vnet.ibm.com wrote:
> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> 
> The current implementation of kvmtrace uses always a 64 bit cycle variable,
> but get_cycles() which is used to fill it is "unsigned long" which might be 32
> bit.
> This reduces the accuracy e.g. on embedded powerpc since we would have a 64bit
> value but get_cycle() only returns the low 32 bit.
> To solve that this patch introduces kvm_arch_trace_cycles() which allows us
> to make this calculation architecture aware. That way every architecture can
> insert whatever fits best for their "kvmtrace cycle counter".
> 
> Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

"cycles" is a very poor name, because that's not really what we're
talking about at all. (Also, that function name made me wonder what a
"trace cycle" is. :)

I would strongly prefer using "timestamp" instead. It would be nice if
we could rename the data structure too, but I'd settle for only properly
naming the new architecture function hook.

In fact, if we want to be rigorous about it, it should really be
something like "nanoseconds" instead, so that userspace wouldn't need to
perform awkward conversions of "cycles" or "timebase ticks" to real
time. It looks like getnstimeofday() would do the trick, and that way we
wouldn't need an arch-specific hook at all.

-- 
Hollis Blanchard
IBM Linux Technology Center