On 9/26/2008 6:55:54 PM, H. Peter Anvin wrote:
quoted text
> Nakajima, Jun wrote:
> > > >
> > > Agreed.  However, that's obviously beyond our immediate control.
> >
> > Well, actually it's under full control of the Linux community
> > because the _kernel_ defines such virtual or semi-hardware features.
> > I'm not sure if that particular value (0x40000010) is proper, but we
> > should be able to pick reasonable ones/ranges.
> >
>
> Uhm, no, they're defined by the _hypervisor_.
>
>         -hpa

Obviously the hypervisor implements such features, and the features available/exposed are up to the hypervisor. My point is that the kernel community can define such generic hypervisor features for Linux because the Linux kernel code needs to be modified anyway. Otherwise, each VMM vender could start changing the kernel in a random fashion. Or nothing happens...

Today each hypervisor already defines and implements such features (or API), and they would need some kind of translation layer to support such Linux hypervisor features (if defined) or they just need to write code.

Having said that,
+       if (cpu_has_hypervisor) {
+               max_cpuid_leaf = cpuid_eax(HYPERVISOR_INFO_LEAF);
+               if (max_cpuid_leaf >= HYPERVISOR_TIMING_LEAF) {
+                       tsc_khz = cpuid_eax(HYPERVISOR_TIMING_LEAF);
+                       printk(KERN_INFO
+                               "TSC frequency read from hypervisor\n");
+                       return tsc_khz;

To have more flexibility and extendability in terms of "supported/unsupported", I think we should use the bitmap first to detect the features as the native does. For example, some hypervisor does not want to implement HYPERVISOR_TIMING_LEAF, but want to implement something higher one (which could be defined in the future).


             .
Jun Nakajima | Intel Open Source Technology Center