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

> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Thursday, September 18, 2014 10:18 AM
> To: Nakajima, Jun; KY Srinivasan
> Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov;
Niels
> Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux
> Virtualization
> Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed?
> 
> Il 18/09/2014 19:13, Nakajima, Jun ha scritto:
> > In terms of the address for the MSR, I suggest that you choose one
> > from the range between 40000000H - 400000FFH. The SDM (35.1
> > ARCHITECTURAL MSRS) says "All existing and future processors will
not
> > implement any features using any MSR in this range." Hyper-V
already
> > defines many synthetic MSRs in this range, and I think it would be
> > reasonable for you to pick one for this to avoid a conflict?
> 
> KVM is not using any MSR in that range.
> 
> However, I think it would be better to have the MSR (and perhaps CPUID)
> outside the hypervisor-reserved ranges, so that it becomes architecturally
> defined.  In some sense it is similar to the HYPERVISOR CPUID feature.
Yes, given that we want this to be hypervisor agnostic.

K. Y

On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan <kys at microsoft.com>
wrote:
>
>
>> -----Original Message-----
>> From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of
Paolo
>> Bonzini
>> Sent: Thursday, September 18, 2014 10:18 AM
>> To: Nakajima, Jun; KY Srinivasan
>> Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb
Natapov; Niels
>> Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins;
Linux
>> Virtualization
>> Subject: Re: Standardizing an MSR or other hypercall to get an RNG
seed?
>>
>> Il 18/09/2014 19:13, Nakajima, Jun ha scritto:
>> > In terms of the address for the MSR, I suggest that you choose one
>> > from the range between 40000000H - 400000FFH. The SDM (35.1
>> > ARCHITECTURAL MSRS) says "All existing and future processors
will not
>> > implement any features using any MSR in this range." Hyper-V
already
>> > defines many synthetic MSRs in this range, and I think it would be
>> > reasonable for you to pick one for this to avoid a conflict?
>>
>> KVM is not using any MSR in that range.
>>
>> However, I think it would be better to have the MSR (and perhaps CPUID)
>> outside the hypervisor-reserved ranges, so that it becomes
architecturally
>> defined.  In some sense it is similar to the HYPERVISOR CPUID feature.
>
> Yes, given that we want this to be hypervisor agnostic.
>
Actually, that MSR address range has been reserved for that purpose, along with:
- CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal)
- CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID)


-- 
Jun
Intel Open Source Technology Center

On Thu, Sep 18, 2014 at 10:42 AM, Nakajima, Jun <jun.nakajima at
intel.com> wrote:
> On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan <kys at
microsoft.com> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf
Of Paolo
>>> Bonzini
>>> Sent: Thursday, September 18, 2014 10:18 AM
>>> To: Nakajima, Jun; KY Srinivasan
>>> Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb
Natapov; Niels
>>> Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake
Oshins; Linux
>>> Virtualization
>>> Subject: Re: Standardizing an MSR or other hypercall to get an RNG
seed?
>>>
>>> Il 18/09/2014 19:13, Nakajima, Jun ha scritto:
>>> > In terms of the address for the MSR, I suggest that you choose
one
>>> > from the range between 40000000H - 400000FFH. The SDM (35.1
>>> > ARCHITECTURAL MSRS) says "All existing and future
processors will not
>>> > implement any features using any MSR in this range."
Hyper-V already
>>> > defines many synthetic MSRs in this range, and I think it
would be
>>> > reasonable for you to pick one for this to avoid a conflict?
>>>
>>> KVM is not using any MSR in that range.
>>>
>>> However, I think it would be better to have the MSR (and perhaps
CPUID)
>>> outside the hypervisor-reserved ranges, so that it becomes
architecturally
>>> defined.  In some sense it is similar to the HYPERVISOR CPUID
feature.
>>
>> Yes, given that we want this to be hypervisor agnostic.
>>
>
> Actually, that MSR address range has been reserved for that purpose, along
with:
> - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal)
> - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID)
I don't know whether this is documented anywhere, but Linux tries to
detect a hypervisor by searching CPUID leaves 0x400xyz00 for
"KVMKVMKVM\0\0\0", so at least Linux can handle the KVM leaves being
in a somewhat variable location.

Do we consider this mechanism to work across all hypervisors and
guests?  That is, could we put something like "CrossHVPara\0"
somewhere in that range, where each hypervisor would be free to decide
exactly where it ends up?

--Andy

> >> However, I think it would be better to have the MSR (and perhaps
CPUID)
> >> outside the hypervisor-reserved ranges, so that it becomes
architecturally
> >> defined.  In some sense it is similar to the HYPERVISOR CPUID
feature.
> >
> > Yes, given that we want this to be hypervisor agnostic.
> 
> Actually, that MSR address range has been reserved for that purpose, along
> with:
> - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal)
> - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID)
No, that has been reserved for hypervisor-specific information (same for the
MSR).
Here we want a feature that is standardized across all hypervisors.

Of course we could just agree to have a common 4000_00C0H to 4000_00FFH range
agreed upon by KVM/Xen/Hyper-V/VMware for both MSRs and CPUID.  But it would
be nice for Intel to act as the registrar, also because this particular
feature in principle can be implemented by processors too (not that it makes
much sense since you could use RDRAND, but it _could_).

Paolo