On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin <david...@microsoft.com> wrote: > I'm not sure what you mean by "this mechanism?" Are you suggesting that each > hypervisor put "CrossHVPara\0" somewhere in the 0x40000000 - 0x400fffff CPUID > range, and an OS has to do a full scan of this CPUID range on boot to find > it? That seems pretty inefficient. An OS will take 1000's of hypervisor > intercepts on every boot just to search this CPUID range.
Linux already does this, which is arguably unfortunate. But it's not quite that bad; the KVM and Xen code is only scanning at increments of 0x100. I think that Linux as a guest would have no problem with checking the Hyper-V range or some new range. I don't think that Linux would want to have to set a guest OS identity, and it's not entirely clear to me whether this would be necessary to use the Hyper-V mechanism. > > I suggest we come to consensus on a specific CPUID leaf where an OS needs to > look to determine if a hypervisor supports this capability. We could define > a new CPUID leaf range at a well-defined location, or we could just use one > of the existing CPUID leaf ranges implemented by an existing hypervisor. I'm > not familiar with the KVM CPUID leaf range, but in the case of Hyper-V, the > Hyper-V CPUID leaf range was architected to allow for other hypervisors to > implement it and just show through specific capabilities supported by the > hypervisor. So, we could define a bit in the Hyper-V CPUID leaf range (since > Xen and KVM also implement this range), but that would require Linux to look > in that range on boot to discover this capability. I also don't know whether QEMU and KVM would be okay with implementing the host side of the Hyper-V mechanism by default. They would have to implement at least leaves 0x40000001 and 0x4000002, plus correctly reporting zeros through whatever leaf is used for this new feature. Gleb? Paolo? --Andy -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
