On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima@xxxxxxxxx> wrote: >> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> >>> 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. >>> >> >> Why do you need a wider MSR range if you always detect the feature by >> CPUID.0x48000001? >> Or are you still trying to avoid the detection by CPUID? > > Detecting the feature is one thing, but figuring out the MSR index is > another. We could shove the index into the cpuid leaf, but that seems > unnecessarily indirect. I'd much rather just say that CPUID leaves > *and* MSR indexes 0x48000000-0x4800ffff or so are reserved for the > cross-HV mechanism, but we can't do that without either knowingly > violating the SDM assignments or asking Intel to consider allocating > more MSR indexes. > > Also, KVM is already conflicting with the SDM right now in its MSR > choice :( I *think* that KVM could be changed to fix that, but 256 > MSRs is rather confining given that KVM currently implements its own > MSR index *and* part of the Hyper-V index. Correction and update: KVM currently implements its own MSRs and, optionally, some of the Hyper-V MSRs. By my count, Linux knows about 68 Hyper-V MSRs (in a header file), and there are current 7 KVM MSRs, so over 1/4 of the available MSR indices are taken (and even more would be taken if KVM were to move its MSRs into the correct range). --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
