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. Thanks... David -----Original Message----- From: Andy Lutomirski [mailto:luto@xxxxxxxxxxxxxx] Sent: Thursday, September 18, 2014 12:07 PM To: Paolo Bonzini Cc: Jun Nakajima; KY Srinivasan; Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels Ferguson; David Hepkin; H. Peter Anvin; Jake Oshins; Linux Virtualization Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed? On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > >> > Actually, that MSR address range has been reserved for that >> > purpose, along >> > with: >> > - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal) >> > - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID) >> >> I don't know whether this is documented anywhere, but Linux tries to >> detect a hypervisor by searching CPUID leaves 0x400xyz00 for >> "KVMKVMKVM\0\0\0", so at least Linux can handle the KVM leaves being >> in a somewhat variable location. >> >> Do we consider this mechanism to work across all hypervisors and >> guests? That is, could we put something like "CrossHVPara\0" >> somewhere in that range, where each hypervisor would be free to >> decide exactly where it ends up? > > That's also possible, but extending the hypervisor CPUID range beywond > 400000FFH is not officially sanctioned by Intel. > > Xen started doing that in order to expose both Hyper-V and Xen CPUID > leaves, and KVM followed the practice. > Whoops. Might Intel be willing to extend that range to 0x40000000 - 0x400fffff? And would Microsoft be okay with using this mechanism for discovery? Do we have anyone from VMware in this thread? I don't have any VMware contacts. --Andy _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
