Re: Xen & VMI?

[Dan Hecht]

On 03/07/2007 12:15 AM, Ingo Molnar wrote:
> On the other hand, Linux's internal details, semantics, approaches are a 
> lot more ad-hoc and alot more affected by changes in the hardware 
> environment - that's why i'd not like to see some external ABI 
> constraint limit aspects of those internals.
>
> For example, VMI_CALL_SetAlarm takes a 'cycles' argument. Cycles is a 
> quite bad unit for an API, it should be absolute time, nanosec or 
> picosec based instead. We could easily see CPUs that have /no concept of 
> cycles/, at all! Even today's CPUs have hardly any fix concept of 
> cycles, due to cpufreq. It's as if 15 years ago we had based sys_mmap() 
> around the concept of '16-bit segments'. We could certainly make it work 
> on current hardware but it would look pretty awkward today.

Ingo,

In the VMI definition, "cycles" does not mean "cpu cycles".  It is used 
in the normal way to mean "an interval of time during which a sequence 
of a recurring succession of events or phenomena is completed" 
[Merriam-Webster].  In this case, the recurring event is the increment 
of a counter.  The routine VMI_CALL_GetCycleFrequency defines how many 
of these events occur per second.  The rate is not variable, so is not 
subject to cpu phenomena such as cpufreq.  And it does not need to be 
tied in any way to cpu cycle frequency.  How your cpu is implemented is 
not relevant.

If a hypervisor wishes to expose it's time counters in units of 
nanoseconds, then it simply returns 1000000000 from GetCycleFrequency.

Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/