>>> On 17.04.13 at 12:16, "Michael S. Tsirkin" wrote:
> If the hypervisor says it's Hyper-V, that's because it wants
> guests to use Hyper-V. I don't see why is guest second-guessing
> this a good idea.
There are two reasons here: For one, when the hypervisor is not
Hyper-V, but is providing some Hyper-V emulation, that's intended
for Windows guests to use, not e.g. Linux ones, especially when
such guests could use the native hypervisor interface with much
greater benefit.
And second, there reportedly are features of (newer?) Hyper-V
that some emulation may not provide, but that are also not easily
detectable.
On Wed, Apr 17, 2013 at 12:10:01PM +0300, Victor Miasnikov wrote:
Question is very simple: Hyper-V users/sysadmins need wait patch a-la this:
Or "KVM_and_or_XEN_or_other_Hypervisor_what_has_non-full-emulation_of_Hyper-V emulates Hyper-V" as "Hyper-V emulates
Hyper-V" ?
No. You are using Hyper-V, not the KVM_and_or_XEN_or_other_Hypervisor_what_has_non-full-emulation_of_Hyper-V
emulation of it.
No patches dealing with this emulation should have any effect on you.
==
+ /*
+ * KVM_and_or_XEN_or_other_Hypervisor_what_has_non-full-emulation_of_Hyper-V emulates Hyper-V to support
enlightened Windows.
+ * Check to see first if we are on a KVM_and_or_XEN_or_other_Hypervisor_what_has_non-full-emulation_of_Hyper-V
Hypervisor.
+ */
+
+ if (KVM_and_or_XEN_or_other_Hypervisor_what_has_non-full-emulation_of_Hyper-V_cpuid_base())
+ return false;
If the hypervisor says it's Hyper-V, that's because it wants guests to use Hyper-V.
==
KVM_and_or_XEN_or_other_Hypervisor_what_has_non-full-emulation_of_Hyper-V emulates Hyper-V to host enlightened
Windows.
. . .
[ hpa: the problem here is that
KVM_and_or_XEN_or_other_Hypervisor_what_has_non-full-emulation_of_Hyper-V doesn't emulate Hyper-V well enough, .
. ]
What's emulated not well enough?
It seems that one might want to use hyper-v emulation e.g. to test
hyper-v code without using windows, so the functionality
that this patch disables is not completely useless,
so there should be a good reason for disabling it.
I went over the original discussion in
https://patchwork.kernel.org/patch/2064331/
and that's still not clear to me. Is there a configuration
that is broken without this patch but starts working with
this patch?