On Mon, 2008-07-07 at 15:56 +0200, ehrhardt@xxxxxxxxxxxxxxxxxx wrote: > From: Christian Ehrhardt <ehrhardt@xxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxx> "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 -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
