On 09/18/2014 02:46 PM, David Hepkin 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.
>
> 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.
>
Yes, I would agree that if anything we should define a new range unique
to this cross-VM interface, e.g. 0x48000000.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html