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

On Thu, Sep 18, 2014 at 2:57 PM, H. Peter Anvin <hpa at zytor.com>
wrote:
> On 09/18/2014 02:46 PM, David Hepkin wrote:
>> 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.
>>
>
> Yes, I would agree that if anything we should define a new range unique
> to this cross-VM interface, e.g. 0x48000000.
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.

2. Who would host and maintain such a spec?  I could do it on github,
but this seems a bit silly.  Other options would include Intel,
Microsoft, or perhaps the Linux Foundation.  I don't know whether
Intel or LF would want to do this, and MS isn't exactly
vendor-neutral.  (Even L-F isn't entirely neutral, since they sort of
represent two hypervisors.)  Or we could do something temporary and
then try to work with a group like OASIS, but that might end up being
a lot of work.

--Andy

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?

-- 
Jun
Intel Open Source Technology Center

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