On Thu, Sep 18, 2014 at 03:00:05PM -0700, Andy Lutomirski wrote:
> On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin <[email protected]> wrote:
> > 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.
> 
> I also don't know whether QEMU and KVM would be okay with implementing
> the host side of the Hyper-V mechanism by default.  They would have to
> implement at least leaves 0x40000001 and 0x4000002, plus correctly
> reporting zeros through whatever leaf is used for this new feature.
> Gleb?  Paolo?
> 
KVM and any other hypervisor out there already implement capability
detection mechanism in 0x40000000 range, and of course all of them do
it differently. Linux detects what hypervior it runs on very early and
switch to correspondent code to handle each hypervisor. Quite frankly
I do not see what problem you are trying to fix with standardizing MSR
to get RND and detection mechanism for this MSR. RND MSR is in no way
unique here. There are other mechanisms that are virtually identical
between hypervisors but have different gust/hypervisor interfaces and
are detected differently on different hypervisors. Examples are pvclock,
pveoi may be others.

--
                        Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to