From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Nakajima, Jun" Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed? Date: Fri, 19 Sep 2014 09:14:56 -0700 Message-ID: References: <5b9c7dcde3824e49a25f3ee00844b868@BY2PR0301MB0711.namprd03.prod.outlook.com> <541B13B8.1020006@redhat.com> <1969371640.51211843.1411066715223.JavaMail.zimbra@redhat.com> <0180a8dfcad746a895755c4374853c16@BY2PR03MB585.namprd03.prod.outlook.com> <541B5553.7020203@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Andy Lutomirski Cc: Mathew John , Theodore Ts'o , John Starks , kvm list , Gleb Natapov , Niels Ferguson , Linux Virtualization , David Hepkin , "H. Peter Anvin" , Jake Oshins , Paolo Bonzini List-Id: virtualization@lists.linuxfoundation.org On Thu, Sep 18, 2014 at 6:28 PM, Andy Lutomirski wrote: > On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski wrote: >> On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun wrote: >>> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski 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