On Thu, Sep 18, 2014 at 2:57 PM, H. Peter Anvin <h...@zytor.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
