On Tue, 29 Jan 2013, KY Srinivasan wrote: > > The patch which started this thread is still valid because it enables > > feature B only if the featurebit for B is enabled. > > Why would we need this if we have some other way of detecting that Hyper-V is > being > emulated.
I don't think that Hyper-V being emulated or not matters here. What matters is whether the feature is available: only if it is then it should be used. > Furthermore, I am not sure I understand the logic here. The fact that the > hypervisor > supports PARTITION_REFERENCE_COUNTER does not necessarily mean that we should > register > a clocksource based on that reference counter. It is true that that is the > case on Hyper-V today. > However, on other hypervisors emulating Hyper-V, other standard clocksources > maybe more > appropriate. The point is that if a feature is NOT supported, then it should NOT be used. Only if it is supported, then Linux might consider using it. And of course can decide not to use it. > I agree with you that your patch is valid for making the Hyper-V code more > robust but not for dealing > with general issue of Xen emulating Hyper-V. What "general issue" would that be? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
