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

On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin <hpa at zytor.com>
wrote:
> On 09/18/2014 07:40 AM, KY Srinivasan wrote:
>>>
>>> The main questions are what MSR index to use and how to detect the
>>> presence of the MSR.  I've played with two approaches:
>>>
>>> 1. Use CPUID to detect the presence of this feature.  This is very
easy for
>>> KVM to implement by using a KVM-specific CPUID feature.  The
problem is
>>> that this will necessarily be KVM-specific, as the guest must first
probe for
>>> KVM and then probe for the KVM feature.  I doubt that Hyper-V, for
>>> example, wants to claim to be KVM.  If we could standardize a non-
>>> hypervisor-specific CPUID feature, then this problem would go away.
>>
>> We would prefer a CPUID feature bit to detect this feature.
>>
>
> I guess if we're introducing the concept of pan-OS MSRs we could also
> have pan-OS CPUID.  The real issue is to get a single non-conflicting
> standard.
Agreed.

KVM currently puts 0 in 0x40000000.EAX, meaning that a feature bit in
Microsoft's leaf 0x40000003 would probably not work well for KVM.  I
don't expect that Microsoft wants to start claiming to be KVM for the
purpose of using a KVM-style feature bit, so, if we went the CPUID
route, we would probably need something new.

--Andy
>
>         -hpa
>
>


-- 
Andy Lutomirski
AMA Capital Management, LLC

On Thu, Sep 18, 2014 at 8:38 AM, Andy Lutomirski <luto at amacapital.net>
wrote:
> On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin <hpa at zytor.com>
wrote:
>> On 09/18/2014 07:40 AM, KY Srinivasan wrote:
>>>>
>>>> The main questions are what MSR index to use and how to detect
the
>>>> presence of the MSR.  I've played with two approaches:
>>>>
>>>> 1. Use CPUID to detect the presence of this feature.  This is
very easy for
>>>> KVM to implement by using a KVM-specific CPUID feature.  The
problem is
>>>> that this will necessarily be KVM-specific, as the guest must
first probe for
>>>> KVM and then probe for the KVM feature.  I doubt that Hyper-V,
for
>>>> example, wants to claim to be KVM.  If we could standardize a
non-
>>>> hypervisor-specific CPUID feature, then this problem would go
away.
>>>
>>> We would prefer a CPUID feature bit to detect this feature.
>>>
>>
>> I guess if we're introducing the concept of pan-OS MSRs we could
also
>> have pan-OS CPUID.  The real issue is to get a single non-conflicting
>> standard.
>
> Agreed.
>
> KVM currently puts 0 in 0x40000000.EAX, meaning that a feature bit in
> Microsoft's leaf 0x40000003 would probably not work well for KVM.  I
> don't expect that Microsoft wants to start claiming to be KVM for the
> purpose of using a KVM-style feature bit, so, if we went the CPUID
> route, we would probably need something new.
Slight correction: QEMU/KVM has optional support for Hyper-V feature
enumeration.  Ideally the RNG seed mechanism would be enabled by
default, but I don't know whether the QEMU maintainers would be okay
with enabling the Hyper-V cpuid mechanism in a default configuration.

--Andy
>
> --Andy
>
>>
>>         -hpa
>>
>>
>
>
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC


-- 
Andy Lutomirski
AMA Capital Management, LLC

Il 18/09/2014 17:44, Andy Lutomirski ha scritto:
> Slight correction: QEMU/KVM has optional support for Hyper-V feature
> enumeration.  Ideally the RNG seed mechanism would be enabled by
> default, but I don't know whether the QEMU maintainers would be okay
> with enabling the Hyper-V cpuid mechanism in a default configuration.
Some guests cannot find the KVM leaves at 0x40000100, so it wouldn't be
great.  And I also don't know what VMware folks would think, but I think
they would be even less thrilled than me.

Note that even if there is no well-defined CPUID leaf, and the main
detection mechanism is #GP, each hypervisor is free to define a CPUID
bit of its own.

However, if it's going to be an architectural (Intel-defined) MSR, I
think the right place for a feature bit is in the low leaves (like
EAX=7, ECX=0).

Paolo

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto at amacapital.net]
> Sent: Thursday, September 18, 2014 8:38 AM
> To: H. Peter Anvin
> Cc: KY Srinivasan; Linux Virtualization; kvm list; Gleb Natapov; Paolo
Bonzini;
> Theodore Ts'o
> Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed?
> 
> On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin <hpa at zytor.com>
wrote:
> > On 09/18/2014 07:40 AM, KY Srinivasan wrote:
> >>>
> >>> The main questions are what MSR index to use and how to detect
the
> >>> presence of the MSR.  I've played with two approaches:
> >>>
> >>> 1. Use CPUID to detect the presence of this feature.  This is
very
> >>> easy for KVM to implement by using a KVM-specific CPUID
feature.
> >>> The problem is that this will necessarily be KVM-specific, as
the
> >>> guest must first probe for KVM and then probe for the KVM
feature.
> >>> I doubt that Hyper-V, for example, wants to claim to be KVM. 
If we
> >>> could standardize a non- hypervisor-specific CPUID feature,
then this
> problem would go away.
> >>
> >> We would prefer a CPUID feature bit to detect this feature.
> >>
> >
> > I guess if we're introducing the concept of pan-OS MSRs we could
also
> > have pan-OS CPUID.  The real issue is to get a single non-conflicting
> > standard.
> 
> Agreed.
> 
> KVM currently puts 0 in 0x40000000.EAX, meaning that a feature bit in
> Microsoft's leaf 0x40000003 would probably not work well for KVM.  I
don't
> expect that Microsoft wants to start claiming to be KVM for the purpose of
> using a KVM-style feature bit, so, if we went the CPUID route, we would
> probably need something new.
> 
> --Andy
I am copying other Hyper-V engineers to this discussion.

Regards,

K. Y
> 
> >
> >         -hpa
> >
> >
> 
> 
> 
> --
> Andy Lutomirski
> AMA Capital Management, LLC

On Thu, Sep 18, 2014 at 9:36 AM, KY Srinivasan <kys at microsoft.com>
wrote:
>
> I am copying other Hyper-V engineers to this discussion.
>
Thanks, K.Y.

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?

-- 
Jun
Intel Open Source Technology Center