On Thu, Sep 18, 2014 at 6:28 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > 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). > I slept on it, and I think using the CPUID instruction alone would be simple and efficient: - We have a huge space for CPUID leaves - CPUID also works for user-level - It can take an additional 32-bit parameter (ECX), and returns 4 32-bit values (EAX, EBX, ECX, and EDX). RDMSR, for example, returns a 64-bit value. Basically we can use it to implement a hypercall (rather than VMCALL). For example, - CPUID 0x48000001.EAX would return the feature presence (e.g. in EBX), and the result in EDX:EAX (if present) at the same time, or - CPUID 0x48000001.EAX would return the feature presence only, and CPUID 0x48000002.EAX (acts like a hypercall) returns up to 4 32-bit values. -- Jun Intel Open Source Technology Center -- 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
