Linux Virtualization - Sep 2014 - Standardizing an MSR or other hypercall to get an RNG seed?

On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima at intel.com>
wrote:
> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto at
amacapital.net> 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.

--Andy

On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski <luto at amacapital.net>
wrote:
> On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima at
intel.com> wrote:
>> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto at
amacapital.net> 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

On Thu, Sep 18, 2014 at 6:28 PM, Andy Lutomirski <luto at amacapital.net>
wrote:
> On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski <luto at
amacapital.net> wrote:
>> On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima at
intel.com> wrote:
>>> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto at
amacapital.net> 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