| Message ID | 1374572465-15278-4-git-send-email-jasowang@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Il 23/07/2013 11:41, Jason Wang ha scritto: > Recent kvm has some basic support of hyperv, this will cause the guest to > identify itself as running on top of hyperv instead of kvm which will disable > kvm pv functionality. This is because we try to detect hyperv before kvm. Solve > this by simply checking kvm in detect_hypervisor() first. > > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > Cc: x86@kernel.org > Cc: Gleb Natapov <gleb@redhat.com> > Cc: Paolo Bonzini <pbonzini@redhat.com> > Cc: K. Y. Srinivasan <kys@microsoft.com> > Signed-off-by: Jason Wang <jasowang@redhat.com> > --- > arch/x86/kernel/cpu/hypervisor.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c > index 8727921..3e149b6 100644 > --- a/arch/x86/kernel/cpu/hypervisor.c > +++ b/arch/x86/kernel/cpu/hypervisor.c > @@ -36,10 +36,10 @@ static const __initconst struct hypervisor_x86 * const hypervisors[] = > &x86_hyper_xen_hvm, > #endif > &x86_hyper_vmware, > - &x86_hyper_ms_hyperv, > #ifdef CONFIG_KVM_GUEST > &x86_hyper_kvm, > #endif > + &x86_hyper_ms_hyperv, > }; > > const struct hypervisor_x86 *x86_hyper; > Acked-by: Paolo Bonzini <pbonzini@redhat.com> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Jason Wang [mailto:jasowang@redhat.com] > Sent: Tuesday, July 23, 2013 5:41 AM > To: tglx@linutronix.de; mingo@redhat.com; hpa@zytor.com; x86@kernel.org; > gleb@redhat.com; pbonzini@redhat.com; kvm@vger.kernel.org; linux- > kernel@vger.kernel.org > Cc: Jason Wang; KY Srinivasan > Subject: [PATCH 4/4] x86: properly handle kvm emulation of hyperv > > Recent kvm has some basic support of hyperv, this will cause the guest to > identify itself as running on top of hyperv instead of kvm which will disable > kvm pv functionality. This is because we try to detect hyperv before kvm. Solve > this by simply checking kvm in detect_hypervisor() first. > This strategy of hypervisor detection based on some detection order IMHO is not a robust detection strategy. The current scheme works since the only hypervisor emulated (by other hypervisors happens to be Hyper-V). What if this were to change. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/23/2013 06:55 AM, KY Srinivasan wrote: > > This strategy of hypervisor detection based on some detection order IMHO is not > a robust detection strategy. The current scheme works since the only hypervisor emulated > (by other hypervisors happens to be Hyper-V). What if this were to change. > One strategy would be to pick the *last* one in the CPUID list, since the ones before it are logically the one(s) being emulated... -hpa -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: H. Peter Anvin [mailto:hpa@zytor.com] > Sent: Tuesday, July 23, 2013 10:48 AM > To: KY Srinivasan > Cc: Jason Wang; tglx@linutronix.de; mingo@redhat.com; x86@kernel.org; > gleb@redhat.com; pbonzini@redhat.com; kvm@vger.kernel.org; linux- > kernel@vger.kernel.org > Subject: Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv > > On 07/23/2013 06:55 AM, KY Srinivasan wrote: > > > > This strategy of hypervisor detection based on some detection order IMHO is > not > > a robust detection strategy. The current scheme works since the only > hypervisor emulated > > (by other hypervisors happens to be Hyper-V). What if this were to change. > > > > One strategy would be to pick the *last* one in the CPUID list, since > the ones before it are logically the one(s) being emulated... Is it always possible to guarantee this ordering. As a hypothetical, what if hypervisor A emulates Hypervisor B and Hypervisor B emulates Hypervisor A. In this case we cannot have any "order" based detection that can yield "correct" detection. I define "correctness" as follows: If a guest can run on both the hypervisors, the guest should detect the true native Hypervisor. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/23/2013 10:45 AM, KY Srinivasan wrote: >> >> One strategy would be to pick the *last* one in the CPUID list, since >> the ones before it are logically the one(s) being emulated... > > Is it always possible to guarantee this ordering. As a hypothetical, what if hypervisor A > emulates Hypervisor B and Hypervisor B emulates Hypervisor A. In this case we cannot > have any "order" based detection that can yield "correct" detection. I define "correctness" > as follows: > > If a guest can run on both the hypervisors, the guest should detect the true native > Hypervisor. > My point was that most hypervisors tend to put the native signature at the end of the list starting at 0x40000000, just to deal with naïve guests which only look at 0x40000000 and not beyond. So a natural convention would be to "use the last entry in the list you know how to handle." -hpa -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: H. Peter Anvin [mailto:hpa@zytor.com] > Sent: Tuesday, July 23, 2013 2:46 PM > To: KY Srinivasan > Cc: Jason Wang; tglx@linutronix.de; mingo@redhat.com; x86@kernel.org; > gleb@redhat.com; pbonzini@redhat.com; kvm@vger.kernel.org; linux- > kernel@vger.kernel.org > Subject: Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv > > On 07/23/2013 10:45 AM, KY Srinivasan wrote: > >> > >> One strategy would be to pick the *last* one in the CPUID list, since > >> the ones before it are logically the one(s) being emulated... > > > > Is it always possible to guarantee this ordering. As a hypothetical, what if > hypervisor A > > emulates Hypervisor B and Hypervisor B emulates Hypervisor A. In this case we > cannot > > have any "order" based detection that can yield "correct" detection. I define > "correctness" > > as follows: > > > > If a guest can run on both the hypervisors, the guest should detect the true > native > > Hypervisor.at > > > > My point was that most hypervisors tend to put the native signature at > the end of the list starting at 0x40000000, just to deal with naïve > guests which only look at 0x40000000 and not beyond. So a natural > convention would be to "use the last entry in the list you know how to > handle." Ok; thanks for the clarification. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/23/2013 10:48 PM, H. Peter Anvin wrote: > On 07/23/2013 06:55 AM, KY Srinivasan wrote: >> This strategy of hypervisor detection based on some detection order IMHO is not >> a robust detection strategy. The current scheme works since the only hypervisor emulated >> (by other hypervisors happens to be Hyper-V). What if this were to change. >> > One strategy would be to pick the *last* one in the CPUID list, since > the ones before it are logically the one(s) being emulated... > > -hpa > How about simply does a reverse loop from 0x40010000 to 0x40010000? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/23/2013 09:37 PM, Jason Wang wrote: > On 07/23/2013 10:48 PM, H. Peter Anvin wrote: >> On 07/23/2013 06:55 AM, KY Srinivasan wrote: >>> This strategy of hypervisor detection based on some detection order IMHO is not >>> a robust detection strategy. The current scheme works since the only hypervisor emulated >>> (by other hypervisors happens to be Hyper-V). What if this were to change. >>> >> One strategy would be to pick the *last* one in the CPUID list, since >> the ones before it are logically the one(s) being emulated... >> >> -hpa >> > > How about simply does a reverse loop from 0x40010000 to 0x40010000? > Not all systems like being poked too far into hyperspace. Just remember the last match and walk the list. -hpa -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/24/2013 12:48 PM, H. Peter Anvin wrote: > On 07/23/2013 09:37 PM, Jason Wang wrote: >> On 07/23/2013 10:48 PM, H. Peter Anvin wrote: >>> On 07/23/2013 06:55 AM, KY Srinivasan wrote: >>>> This strategy of hypervisor detection based on some detection order IMHO is not >>>> a robust detection strategy. The current scheme works since the only hypervisor emulated >>>> (by other hypervisors happens to be Hyper-V). What if this were to change. >>>> >>> One strategy would be to pick the *last* one in the CPUID list, since >>> the ones before it are logically the one(s) being emulated... >>> >>> -hpa >>> >> How about simply does a reverse loop from 0x40010000 to 0x40010000? >> > Not all systems like being poked too far into hyperspace. Just remember > the last match and walk the list. > > -hpa > Ok, but it raises a question - how to know it was the 'last' match without knowing all signatures of other hyper-visor? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Il 24/07/2013 08:54, Jason Wang ha scritto: > On 07/24/2013 12:48 PM, H. Peter Anvin wrote: >> On 07/23/2013 09:37 PM, Jason Wang wrote: >>> On 07/23/2013 10:48 PM, H. Peter Anvin wrote: >>>> On 07/23/2013 06:55 AM, KY Srinivasan wrote: >>>>> This strategy of hypervisor detection based on some detection order IMHO is not >>>>> a robust detection strategy. The current scheme works since the only hypervisor emulated >>>>> (by other hypervisors happens to be Hyper-V). What if this were to change. >>>>> >>>> One strategy would be to pick the *last* one in the CPUID list, since >>>> the ones before it are logically the one(s) being emulated... >>>> >>>> -hpa >>>> >>> How about simply does a reverse loop from 0x40010000 to 0x40010000? >>> >> Not all systems like being poked too far into hyperspace. Just remember >> the last match and walk the list. >> >> -hpa >> > > Ok, but it raises a question - how to know it was the 'last' match > without knowing all signatures of other hyper-visor? You can return a "priority" value from the .detect function. The priority value can simply be the CPUID leaf where the signature was found (or a low value such as 1 if detection was done with DMI). Then you can pick the hypervisor with the highest priority instead of hard-coding the order. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo > Bonzini > Sent: Wednesday, July 24, 2013 3:07 AM > To: Jason Wang > Cc: H. Peter Anvin; KY Srinivasan; tglx@linutronix.de; mingo@redhat.com; > x86@kernel.org; gleb@redhat.com; kvm@vger.kernel.org; linux- > kernel@vger.kernel.org > Subject: Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv > > Il 24/07/2013 08:54, Jason Wang ha scritto: > > On 07/24/2013 12:48 PM, H. Peter Anvin wrote: > >> On 07/23/2013 09:37 PM, Jason Wang wrote: > >>> On 07/23/2013 10:48 PM, H. Peter Anvin wrote: > >>>> On 07/23/2013 06:55 AM, KY Srinivasan wrote: > >>>>> This strategy of hypervisor detection based on some detection order > IMHO is not > >>>>> a robust detection strategy. The current scheme works since the only > hypervisor emulated > >>>>> (by other hypervisors happens to be Hyper-V). What if this were to > change. > >>>>> > >>>> One strategy would be to pick the *last* one in the CPUID list, since > >>>> the ones before it are logically the one(s) being emulated... > >>>> > >>>> -hpa > >>>> > >>> How about simply does a reverse loop from 0x40010000 to 0x40010000? > >>> > >> Not all systems like being poked too far into hyperspace. Just remember > >> the last match and walk the list. > >> > >> -hpa > >> > > > > Ok, but it raises a question - how to know it was the 'last' match > > without knowing all signatures of other hyper-visor? > > You can return a "priority" value from the .detect function. The > priority value can simply be the CPUID leaf where the signature was > found (or a low value such as 1 if detection was done with DMI). > > Then you can pick the hypervisor with the highest priority instead of > hard-coding the order. I like this idea; this allows some guest level control that is what we want when we have hypervisors emulating each other. Regards, K. Y > > Paolo > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I don't see how this solves the A emulates B, B emulates A problem? KY Srinivasan <kys@microsoft.com> wrote: > > >> -----Original Message----- >> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of >Paolo >> Bonzini >> Sent: Wednesday, July 24, 2013 3:07 AM >> To: Jason Wang >> Cc: H. Peter Anvin; KY Srinivasan; tglx@linutronix.de; >mingo@redhat.com; >> x86@kernel.org; gleb@redhat.com; kvm@vger.kernel.org; linux- >> kernel@vger.kernel.org >> Subject: Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv >> >> Il 24/07/2013 08:54, Jason Wang ha scritto: >> > On 07/24/2013 12:48 PM, H. Peter Anvin wrote: >> >> On 07/23/2013 09:37 PM, Jason Wang wrote: >> >>> On 07/23/2013 10:48 PM, H. Peter Anvin wrote: >> >>>> On 07/23/2013 06:55 AM, KY Srinivasan wrote: >> >>>>> This strategy of hypervisor detection based on some detection >order >> IMHO is not >> >>>>> a robust detection strategy. The current scheme works since the >only >> hypervisor emulated >> >>>>> (by other hypervisors happens to be Hyper-V). What if this were >to >> change. >> >>>>> >> >>>> One strategy would be to pick the *last* one in the CPUID list, >since >> >>>> the ones before it are logically the one(s) being emulated... >> >>>> >> >>>> -hpa >> >>>> >> >>> How about simply does a reverse loop from 0x40010000 to >0x40010000? >> >>> >> >> Not all systems like being poked too far into hyperspace. Just >remember >> >> the last match and walk the list. >> >> >> >> -hpa >> >> >> > >> > Ok, but it raises a question - how to know it was the 'last' match >> > without knowing all signatures of other hyper-visor? >> >> You can return a "priority" value from the .detect function. The >> priority value can simply be the CPUID leaf where the signature was >> found (or a low value such as 1 if detection was done with DMI). >> >> Then you can pick the hypervisor with the highest priority instead of >> hard-coding the order. > >I like this idea; this allows some guest level control that is what we >want >when we have hypervisors emulating each other. > > >Regards, > >K. Y >> >> Paolo >> >>
> -----Original Message----- > From: H. Peter Anvin [mailto:hpa@zytor.com] > Sent: Wednesday, July 24, 2013 11:14 AM > To: KY Srinivasan; Paolo Bonzini; Jason Wang > Cc: tglx@linutronix.de; mingo@redhat.com; x86@kernel.org; gleb@redhat.com; > kvm@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv > > I don't see how this solves the A emulates B, B emulates A problem? As Paolo suggested if there were some priority encoded, the guest could make an informed decision. If the guest under question can run on both hypervisors A and B, we would rather the guest discover hypervisor A when running on A and hypervisor B when running on B. The priority encoding could be as simple as surfacing the native hypervisor signature earlier in the CPUID space. K. Y > > KY Srinivasan <kys@microsoft.com> wrote: > > > > > >> -----Original Message----- > >> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of > >Paolo > >> Bonzini > >> Sent: Wednesday, July 24, 2013 3:07 AM > >> To: Jason Wang > >> Cc: H. Peter Anvin; KY Srinivasan; tglx@linutronix.de; > >mingo@redhat.com; > >> x86@kernel.org; gleb@redhat.com; kvm@vger.kernel.org; linux- > >> kernel@vger.kernel.org > >> Subject: Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv > >> > >> Il 24/07/2013 08:54, Jason Wang ha scritto: > >> > On 07/24/2013 12:48 PM, H. Peter Anvin wrote: > >> >> On 07/23/2013 09:37 PM, Jason Wang wrote: > >> >>> On 07/23/2013 10:48 PM, H. Peter Anvin wrote: > >> >>>> On 07/23/2013 06:55 AM, KY Srinivasan wrote: > >> >>>>> This strategy of hypervisor detection based on some detection > >order > >> IMHO is not > >> >>>>> a robust detection strategy. The current scheme works since the > >only > >> hypervisor emulated > >> >>>>> (by other hypervisors happens to be Hyper-V). What if this were > >to > >> change. > >> >>>>> > >> >>>> One strategy would be to pick the *last* one in the CPUID list, > >since > >> >>>> the ones before it are logically the one(s) being emulated... > >> >>>> > >> >>>> -hpa > >> >>>> > >> >>> How about simply does a reverse loop from 0x40010000 to > >0x40010000? > >> >>> > >> >> Not all systems like being poked too far into hyperspace. Just > >remember > >> >> the last match and walk the list. > >> >> > >> >> -hpa > >> >> > >> > > >> > Ok, but it raises a question - how to know it was the 'last' match > >> > without knowing all signatures of other hyper-visor? > >> > >> You can return a "priority" value from the .detect function. The > >> priority value can simply be the CPUID leaf where the signature was > >> found (or a low value such as 1 if detection was done with DMI). > >> > >> Then you can pick the hypervisor with the highest priority instead of > >> hard-coding the order. > > > >I like this idea; this allows some guest level control that is what we > >want > >when we have hypervisors emulating each other. > > > > > >Regards, > > > >K. Y > >> > >> Paolo > >> > >> > > -- > Sent from my mobile phone. Please excuse brevity and lack of formatting. > >
What I'm suggesting is exactly that except that the native hypervisor is later in CPUID space. KY Srinivasan <kys@microsoft.com> wrote: > > >> -----Original Message----- >> From: H. Peter Anvin [mailto:hpa@zytor.com] >> Sent: Wednesday, July 24, 2013 11:14 AM >> To: KY Srinivasan; Paolo Bonzini; Jason Wang >> Cc: tglx@linutronix.de; mingo@redhat.com; x86@kernel.org; >gleb@redhat.com; >> kvm@vger.kernel.org; linux-kernel@vger.kernel.org >> Subject: RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv >> >> I don't see how this solves the A emulates B, B emulates A problem? > >As Paolo suggested if there were some priority encoded, the guest could >make an >informed decision. If the guest under question can run on both >hypervisors A and B, >we would rather the guest discover hypervisor A when running on A and >hypervisor B >when running on B. The priority encoding could be as simple as >surfacing the native hypervisor >signature earlier in the CPUID space. > >K. Y >> >> KY Srinivasan <kys@microsoft.com> wrote: >> > >> > >> >> -----Original Message----- >> >> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of >> >Paolo >> >> Bonzini >> >> Sent: Wednesday, July 24, 2013 3:07 AM >> >> To: Jason Wang >> >> Cc: H. Peter Anvin; KY Srinivasan; tglx@linutronix.de; >> >mingo@redhat.com; >> >> x86@kernel.org; gleb@redhat.com; kvm@vger.kernel.org; linux- >> >> kernel@vger.kernel.org >> >> Subject: Re: [PATCH 4/4] x86: properly handle kvm emulation of >hyperv >> >> >> >> Il 24/07/2013 08:54, Jason Wang ha scritto: >> >> > On 07/24/2013 12:48 PM, H. Peter Anvin wrote: >> >> >> On 07/23/2013 09:37 PM, Jason Wang wrote: >> >> >>> On 07/23/2013 10:48 PM, H. Peter Anvin wrote: >> >> >>>> On 07/23/2013 06:55 AM, KY Srinivasan wrote: >> >> >>>>> This strategy of hypervisor detection based on some >detection >> >order >> >> IMHO is not >> >> >>>>> a robust detection strategy. The current scheme works since >the >> >only >> >> hypervisor emulated >> >> >>>>> (by other hypervisors happens to be Hyper-V). What if this >were >> >to >> >> change. >> >> >>>>> >> >> >>>> One strategy would be to pick the *last* one in the CPUID >list, >> >since >> >> >>>> the ones before it are logically the one(s) being emulated... >> >> >>>> >> >> >>>> -hpa >> >> >>>> >> >> >>> How about simply does a reverse loop from 0x40010000 to >> >0x40010000? >> >> >>> >> >> >> Not all systems like being poked too far into hyperspace. Just >> >remember >> >> >> the last match and walk the list. >> >> >> >> >> >> -hpa >> >> >> >> >> > >> >> > Ok, but it raises a question - how to know it was the 'last' >match >> >> > without knowing all signatures of other hyper-visor? >> >> >> >> You can return a "priority" value from the .detect function. The >> >> priority value can simply be the CPUID leaf where the signature >was >> >> found (or a low value such as 1 if detection was done with DMI). >> >> >> >> Then you can pick the hypervisor with the highest priority instead >of >> >> hard-coding the order. >> > >> >I like this idea; this allows some guest level control that is what >we >> >want >> >when we have hypervisors emulating each other. >> > >> > >> >Regards, >> > >> >K. Y >> >> >> >> Paolo >> >> >> >> >> >> -- >> Sent from my mobile phone. Please excuse brevity and lack of >formatting. >> >>
Il 24/07/2013 23:37, H. Peter Anvin ha scritto: > What I'm suggesting is exactly that except that the native hypervisor is later in CPUID space. Me too actually. I was just suggesting an implementation of the idea (that takes into account hypervisors detected by other means than CPUID). Paolo > KY Srinivasan <kys@microsoft.com> wrote: >> As Paolo suggested if there were some priority encoded, the guest could make an >> informed decision. If the guest under question can run on both hypervisors A and B, >> we would rather the guest discover hypervisor A when running on A and >> hypervisor B when running on B. The priority encoding could be as simple as >> surfacing the native hypervisor signature earlier in the CPUID space. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/25/2013 03:59 PM, Paolo Bonzini wrote: > Il 24/07/2013 23:37, H. Peter Anvin ha scritto: >> What I'm suggesting is exactly that except that the native hypervisor is later in CPUID space. > Me too actually. > > I was just suggesting an implementation of the idea (that takes into > account hypervisors detected by other means than CPUID). > > Paolo This make sense, will send V2. Thanks >> KY Srinivasan <kys@microsoft.com> wrote: >>> As Paolo suggested if there were some priority encoded, the guest could make an >>> informed decision. If the guest under question can run on both hypervisors A and B, >>> we would rather the guest discover hypervisor A when running on A and >>> hypervisor B when running on B. The priority encoding could be as simple as >>> surfacing the native hypervisor signature earlier in the CPUID space. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c index 8727921..3e149b6 100644 --- a/arch/x86/kernel/cpu/hypervisor.c +++ b/arch/x86/kernel/cpu/hypervisor.c @@ -36,10 +36,10 @@ static const __initconst struct hypervisor_x86 * const hypervisors[] = &x86_hyper_xen_hvm, #endif &x86_hyper_vmware, - &x86_hyper_ms_hyperv, #ifdef CONFIG_KVM_GUEST &x86_hyper_kvm, #endif + &x86_hyper_ms_hyperv, }; const struct hypervisor_x86 *x86_hyper;
Recent kvm has some basic support of hyperv, this will cause the guest to identify itself as running on top of hyperv instead of kvm which will disable kvm pv functionality. This is because we try to detect hyperv before kvm. Solve this by simply checking kvm in detect_hypervisor() first. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Cc: Gleb Natapov <gleb@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Jason Wang <jasowang@redhat.com> --- arch/x86/kernel/cpu/hypervisor.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)