On Thu, Sep 18, 2014 at 2:57 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > 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. So, as a concrete straw-man: CPUID leaf 0x48000000 would return a maximum leaf number in EAX (e.g. 0x48000001) along with a signature value (e.g. "CrossHVPara\0") in EBX, ECX, and EDX. CPUID 0x48000001.EAX would contain an MSR number to read to get a random number if supported and zero if not supported. Questions: 1. Can we use a fixed MSR number? This would be a little bit simpler, but it would depend on getting a wider MSR range from Intel. 2. Who would host and maintain such a spec? I could do it on github, but this seems a bit silly. Other options would include Intel, Microsoft, or perhaps the Linux Foundation. I don't know whether Intel or LF would want to do this, and MS isn't exactly vendor-neutral. (Even L-F isn't entirely neutral, since they sort of represent two hypervisors.) Or we could do something temporary and then try to work with a group like OASIS, but that might end up being a lot of work. --Andy -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
