[PATCH 1/4] x86: introduce hypervisor_cpuid_base()

[PATCH 1/4] x86: introduce hypervisor_cpuid_base()

[Jason Wang]

This patch introduce hypervisor_cpuid_base() which loop test the hypervisor
existence function until the signature match and check the number of leaves if
required. This could be used by Xen/KVM guest to detect the existence of
hypervisor.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: x86@kernel.org
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
 arch/x86/include/asm/processor.h |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 24cf5ae..a8136d0 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -971,6 +971,26 @@ unsigned long calc_aperfmperf_ratio(struct aperfmperf *old,
 	return ratio;
 }
 
+static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
+{
+	uint32_t base, eax, ebx, ecx, edx;
+	char signature[13];
+
+	for (base = 0x40000000; base < 0x40010000; base += 0x100) {
+		cpuid(base, &eax, &ebx, &ecx, &edx);
+		*(uint32_t *)(signature + 0) = ebx;
+		*(uint32_t *)(signature + 4) = ecx;
+		*(uint32_t *)(signature + 8) = edx;
+		signature[12] = 0;
+
+		if (!strcmp(sig, signature) &&
+		    (leaves == 0 || ((eax - base) >= leaves)))
+			return base;
+	}
+
+	return 0;
+}
+
 extern unsigned long arch_align_stack(unsigned long sp);
 extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
 
-- 
1.7.1

[PATCH 2/4] xen: switch to use hypervisor_cpuid_base()

[Jason Wang]

Switch to use hypervisor_cpuid_base() to detect Xen.

Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
 arch/x86/include/asm/xen/hypervisor.h |   16 +---------------
 1 files changed, 1 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
index 125f344..d866959 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -40,21 +40,7 @@ extern struct start_info *xen_start_info;
 
 static inline uint32_t xen_cpuid_base(void)
 {
-	uint32_t base, eax, ebx, ecx, edx;
-	char signature[13];
-
-	for (base = 0x40000000; base < 0x40010000; base += 0x100) {
-		cpuid(base, &eax, &ebx, &ecx, &edx);
-		*(uint32_t *)(signature + 0) = ebx;
-		*(uint32_t *)(signature + 4) = ecx;
-		*(uint32_t *)(signature + 8) = edx;
-		signature[12] = 0;
-
-		if (!strcmp("XenVMMXenVMM", signature) && ((eax - base) >= 2))
-			return base;
-	}
-
-	return 0;
+	return hypervisor_cpuid_base("XenVMMXenVMM", 2);
 }
 
 #ifdef CONFIG_XEN
-- 
1.7.1

Re: [PATCH 2/4] xen: switch to use hypervisor_cpuid_base()

[Paolo Bonzini]

Il 23/07/2013 11:41, Jason Wang ha scritto:
> Switch to use hypervisor_cpuid_base() to detect Xen.
> 
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  arch/x86/include/asm/xen/hypervisor.h |   16 +---------------
>  1 files changed, 1 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
> index 125f344..d866959 100644
> --- a/arch/x86/include/asm/xen/hypervisor.h
> +++ b/arch/x86/include/asm/xen/hypervisor.h
> @@ -40,21 +40,7 @@ extern struct start_info *xen_start_info;
>  
>  static inline uint32_t xen_cpuid_base(void)
>  {
> -	uint32_t base, eax, ebx, ecx, edx;
> -	char signature[13];
> -
> -	for (base = 0x40000000; base < 0x40010000; base += 0x100) {
> -		cpuid(base, &eax, &ebx, &ecx, &edx);
> -		*(uint32_t *)(signature + 0) = ebx;
> -		*(uint32_t *)(signature + 4) = ecx;
> -		*(uint32_t *)(signature + 8) = edx;
> -		signature[12] = 0;
> -
> -		if (!strcmp("XenVMMXenVMM", signature) && ((eax - base) >= 2))
> -			return base;
> -	}
> -
> -	return 0;
> +	return hypervisor_cpuid_base("XenVMMXenVMM", 2);
>  }
>  
>  #ifdef CONFIG_XEN
> 

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Re: [PATCH 2/4] xen: switch to use hypervisor_cpuid_base()

[Konrad Rzeszutek Wilk]

On Tue, Jul 23, 2013 at 05:41:03PM +0800, Jason Wang wrote:
> Switch to use hypervisor_cpuid_base() to detect Xen.
> 
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  arch/x86/include/asm/xen/hypervisor.h |   16 +---------------
>  1 files changed, 1 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
> index 125f344..d866959 100644
> --- a/arch/x86/include/asm/xen/hypervisor.h
> +++ b/arch/x86/include/asm/xen/hypervisor.h
> @@ -40,21 +40,7 @@ extern struct start_info *xen_start_info;
>  
>  static inline uint32_t xen_cpuid_base(void)
>  {
> -	uint32_t base, eax, ebx, ecx, edx;
> -	char signature[13];
> -
> -	for (base = 0x40000000; base < 0x40010000; base += 0x100) {
> -		cpuid(base, &eax, &ebx, &ecx, &edx);
> -		*(uint32_t *)(signature + 0) = ebx;
> -		*(uint32_t *)(signature + 4) = ecx;
> -		*(uint32_t *)(signature + 8) = edx;
> -		signature[12] = 0;
> -
> -		if (!strcmp("XenVMMXenVMM", signature) && ((eax - base) >= 2))
> -			return base;
> -	}
> -
> -	return 0;
> +	return hypervisor_cpuid_base("XenVMMXenVMM", 2);
>  }
>  
>  #ifdef CONFIG_XEN
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[PATCH 3/4] kvm: switch to use hypervisor_cpuid_base()

[Jason Wang]

Switch to use hypervisor_cpuid_base() to detect KVM.

Cc: Gleb Natapov <gleb@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
 arch/x86/include/asm/kvm_para.h |   17 ++---------------
 1 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 695399f..79bd075 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -2,6 +2,7 @@
 #define _ASM_X86_KVM_PARA_H
 
 #include <asm/processor.h>
+#include <asm/hypervisor.h>
 #include <uapi/asm/kvm_para.h>
 
 extern void kvmclock_init(void);
@@ -87,24 +88,10 @@ static inline long kvm_hypercall4(unsigned int nr, unsigned long p1,
 
 static inline bool kvm_para_available(void)
 {
-	unsigned int eax, ebx, ecx, edx;
-	char signature[13];
-
 	if (boot_cpu_data.cpuid_level < 0)
 		return false;	/* So we don't blow up on old processors */
 
-	if (cpu_has_hypervisor) {
-		cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
-		memcpy(signature + 0, &ebx, 4);
-		memcpy(signature + 4, &ecx, 4);
-		memcpy(signature + 8, &edx, 4);
-		signature[12] = 0;
-
-		if (strcmp(signature, "KVMKVMKVM") == 0)
-			return true;
-	}
-
-	return false;
+        return hypervisor_cpuid_base("KVMKVMKVM", 0);
 }
 
 static inline unsigned int kvm_arch_para_features(void)
-- 
1.7.1

Re: [PATCH 3/4] kvm: switch to use hypervisor_cpuid_base()

[Paolo Bonzini]

Il 23/07/2013 11:41, Jason Wang ha scritto:
> Switch to use hypervisor_cpuid_base() to detect KVM.
> 
> Cc: Gleb Natapov <gleb@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: kvm@vger.kernel.org
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  arch/x86/include/asm/kvm_para.h |   17 ++---------------
>  1 files changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 695399f..79bd075 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -2,6 +2,7 @@
>  #define _ASM_X86_KVM_PARA_H
>  
>  #include <asm/processor.h>
> +#include <asm/hypervisor.h>
>  #include <uapi/asm/kvm_para.h>
>  
>  extern void kvmclock_init(void);
> @@ -87,24 +88,10 @@ static inline long kvm_hypercall4(unsigned int nr, unsigned long p1,
>  
>  static inline bool kvm_para_available(void)
>  {
> -	unsigned int eax, ebx, ecx, edx;
> -	char signature[13];
> -
>  	if (boot_cpu_data.cpuid_level < 0)
>  		return false;	/* So we don't blow up on old processors */
>  
> -	if (cpu_has_hypervisor) {
> -		cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
> -		memcpy(signature + 0, &ebx, 4);
> -		memcpy(signature + 4, &ecx, 4);
> -		memcpy(signature + 8, &edx, 4);
> -		signature[12] = 0;
> -
> -		if (strcmp(signature, "KVMKVMKVM") == 0)
> -			return true;
> -	}
> -
> -	return false;
> +        return hypervisor_cpuid_base("KVMKVMKVM", 0);
>  }
>  
>  static inline unsigned int kvm_arch_para_features(void)
> 

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

[PATCH 4/4] x86: properly handle kvm emulation of hyperv

[Jason Wang]

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;
-- 
1.7.1

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[Paolo Bonzini]

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>

RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[KY Srinivasan]

> -----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

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[H. Peter Anvin]

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

RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[KY Srinivasan]

> -----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  

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[H. Peter Anvin]

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

RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[KY Srinivasan]

> -----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

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[Jason Wang]

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?

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[H. Peter Anvin]

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

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[Jason Wang]

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?

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[Paolo Bonzini]

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

RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[KY Srinivasan]

> -----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
> 
> 

RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[H. Peter Anvin]

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
>> 
>> 

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[KY Srinivasan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3247 bytes --]



> -----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.
> 
> 

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[H. Peter Anvin]

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.
>> 
>> 

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[Paolo Bonzini]

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.

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

[Jason Wang]

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.

Re: [PATCH 1/4] x86: introduce hypervisor_cpuid_base()

[H. Peter Anvin]

On 07/23/2013 02:41 AM, Jason Wang wrote:
>  
> +static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
> +{
> +	uint32_t base, eax, ebx, ecx, edx;
> +	char signature[13];
> +
> +	for (base = 0x40000000; base < 0x40010000; base += 0x100) {
> +		cpuid(base, &eax, &ebx, &ecx, &edx);
> +		*(uint32_t *)(signature + 0) = ebx;
> +		*(uint32_t *)(signature + 4) = ecx;
> +		*(uint32_t *)(signature + 8) = edx;
> +		signature[12] = 0;
> +
> +		if (!strcmp(sig, signature) &&
> +		    (leaves == 0 || ((eax - base) >= leaves)))
> +			return base;
> +	}
> +
> +	return 0;
> +}
> +

Hmm... how about:

uint32_t sign[3];

	cpuid(base, &eax, &sign[0], &sign[1], &sign[2]);

	if (!memcmp(sig, sign, 12) && ...);

	-hpa

Re: [PATCH 1/4] x86: introduce hypervisor_cpuid_base()

[Paolo Bonzini]

Il 23/07/2013 12:04, H. Peter Anvin ha scritto:
> On 07/23/2013 02:41 AM, Jason Wang wrote:
>>  
>> +static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
>> +{
>> +	uint32_t base, eax, ebx, ecx, edx;
>> +	char signature[13];
>> +
>> +	for (base = 0x40000000; base < 0x40010000; base += 0x100) {
>> +		cpuid(base, &eax, &ebx, &ecx, &edx);
>> +		*(uint32_t *)(signature + 0) = ebx;
>> +		*(uint32_t *)(signature + 4) = ecx;
>> +		*(uint32_t *)(signature + 8) = edx;
>> +		signature[12] = 0;
>> +
>> +		if (!strcmp(sig, signature) &&
>> +		    (leaves == 0 || ((eax - base) >= leaves)))
>> +			return base;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
> 
> Hmm... how about:
> 
> uint32_t sign[3];
> 
> 	cpuid(base, &eax, &sign[0], &sign[1], &sign[2]);
> 
> 	if (!memcmp(sig, sign, 12) && ...);

That's nicer, though strcmp is what the replaced code used to do in
patches 2 and 3.

Note that memcmp requires the caller to use "KVMKVMKVM\0\0" as the
signature (or alternatively hypervisor_cpuid_base can copy the argument
into another 12-byte local variable).

Paolo

Re: [PATCH 1/4] x86: introduce hypervisor_cpuid_base()

[H. Peter Anvin]

On 07/23/2013 04:16 AM, Paolo Bonzini wrote:
> 
> That's nicer, though strcmp is what the replaced code used to do in
> patches 2 and 3.
> 
> Note that memcmp requires the caller to use "KVMKVMKVM\0\0" as the
> signature (or alternatively hypervisor_cpuid_base can copy the argument
> into another 12-byte local variable).
> 

Which is the actual signature, though...

	-hpa

Re: [PATCH 1/4] x86: introduce hypervisor_cpuid_base()

[Jason Wang]

On 07/24/2013 12:03 AM, H. Peter Anvin wrote:
> On 07/23/2013 04:16 AM, Paolo Bonzini wrote:
>> That's nicer, though strcmp is what the replaced code used to do in
>> patches 2 and 3.
>>
>> Note that memcmp requires the caller to use "KVMKVMKVM\0\0" as the
>> signature (or alternatively hypervisor_cpuid_base can copy the argument
>> into another 12-byte local variable).
>>
> Which is the actual signature, though...
>
> 	-hpa
>
>

Since it's just a minor optimization. How about just keep using the
strcmp()?

Re: [PATCH 1/4] x86: introduce hypervisor_cpuid_base()

[H. Peter Anvin]

On 07/23/2013 09:44 PM, Jason Wang wrote:
> 
> Since it's just a minor optimization. How about just keep using the
> strcmp()?
> 

It's more that it enables the rest of the cleanup, making the code
easier to read.

	-hpa

Re: [PATCH 1/4] x86: introduce hypervisor_cpuid_base()

[Gleb Natapov]

On Tue, Jul 23, 2013 at 05:41:02PM +0800, Jason Wang wrote:
> This patch introduce hypervisor_cpuid_base() which loop test the hypervisor
> existence function until the signature match and check the number of leaves if
> required. This could be used by Xen/KVM guest to detect the existence of
> hypervisor.
> 
Looks good to me.

Since this touches common code, kvm and xen I expect this to be taken
via the tip tree, correct?

> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: "Paolo Bonzini" <pbonzini@redhat.com>
> Cc: Gleb Natapov <gleb@redhat.com>
> Cc: x86@kernel.org
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  arch/x86/include/asm/processor.h |   20 ++++++++++++++++++++
>  1 files changed, 20 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 24cf5ae..a8136d0 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -971,6 +971,26 @@ unsigned long calc_aperfmperf_ratio(struct aperfmperf *old,
>  	return ratio;
>  }
>  
> +static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
> +{
> +	uint32_t base, eax, ebx, ecx, edx;
> +	char signature[13];
> +
> +	for (base = 0x40000000; base < 0x40010000; base += 0x100) {
> +		cpuid(base, &eax, &ebx, &ecx, &edx);
> +		*(uint32_t *)(signature + 0) = ebx;
> +		*(uint32_t *)(signature + 4) = ecx;
> +		*(uint32_t *)(signature + 8) = edx;
> +		signature[12] = 0;
> +
> +		if (!strcmp(sig, signature) &&
> +		    (leaves == 0 || ((eax - base) >= leaves)))
> +			return base;
> +	}
> +
> +	return 0;
> +}
> +
>  extern unsigned long arch_align_stack(unsigned long sp);
>  extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
>  
> -- 
> 1.7.1

--
			Gleb.

Re: [PATCH 1/4] x86: introduce hypervisor_cpuid_base()

[Jason Wang]

On 07/23/2013 09:48 PM, Gleb Natapov wrote:
> On Tue, Jul 23, 2013 at 05:41:02PM +0800, Jason Wang wrote:
>> > This patch introduce hypervisor_cpuid_base() which loop test the hypervisor
>> > existence function until the signature match and check the number of leaves if
>> > required. This could be used by Xen/KVM guest to detect the existence of
>> > hypervisor.
>> > 
> Looks good to me.
>
> Since this touches common code, kvm and xen I expect this to be taken
> via the tip tree, correct?
>
Yes, I think so.