[PATCH 0/3] X86: Deliver Hyper-V interrupts on a seperate IDT vector

[PATCH 0/3] X86: Deliver Hyper-V interrupts on a seperate IDT vector

[K. Y. Srinivasan]

This patch-set implements the functionality to deliver Hyper-V VMBUS interrupts via
a special IDT entry. Xen emulates Hyper-V and I have added code in this patch-set to
properly manage this emulation when Linux is running on Hyper-V.

K. Y. Srinivasan (2):
  X86: Add a check to catch Xen emulation of Hyper-V
  X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

Olaf Hering (1):
  x86: Hyper-V: register clocksource only if its advertised

 arch/x86/include/asm/irq_vectors.h |    4 +-
 arch/x86/include/asm/mshyperv.h    |    4 ++
 arch/x86/kernel/cpu/mshyperv.c     |   54 +++++++++++++++++++++++++++++++++++-
 arch/x86/kernel/entry_32.S         |    9 +++++-
 arch/x86/kernel/entry_64.S         |    7 ++++-
 drivers/xen/events.c               |    7 ++--
 6 files changed, 77 insertions(+), 8 deletions(-)

-- 
1.7.4.1

[PATCH 1/3] x86: Hyper-V: register clocksource only if its advertised

[K. Y. Srinivasan]

From: Olaf Hering <[mailto:olaf@aepfle.de]>

Enable hyperv_clocksource only if its advertised as a feature.
XenServer 6 returns the signature which is checked in
ms_hyperv_platform(), but it does not offer all features. Currently the
clocksource is enabled unconditionally in ms_hyperv_init_platform(), and
the result is a hanging guest.

Hyper-V spec Bit 1 indicates the availability of Partition Reference
Counter.  Register the clocksource only if this bit is set.

The guest in question prints this in dmesg:
 [    0.000000] Hypervisor detected: Microsoft HyperV
 [    0.000000] HyperV: features 0x70, hints 0x0

This bug can be reproduced easily be setting 'viridian=1' in a HVM domU
.cfg file. A workaround without this patch is to boot the HVM guest with
'clocksource=jiffies'.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: stable@kernel.org
Cc: Greg KH <gregkh@linuxfoundation.org>
---
 arch/x86/kernel/cpu/mshyperv.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 0a630dd..646d192 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -68,7 +68,8 @@ static void __init ms_hyperv_init_platform(void)
 	printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
 	       ms_hyperv.features, ms_hyperv.hints);
 
-	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
+	if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
+		clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
-- 
1.7.4.1

[PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[K. Y. Srinivasan]

Xen emulates Hyper-V to host enlightened Windows. Looks like this
emulation may be turned on by default even for Linux guests. Check and
fail Hyper-V detection if we are on Xen.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 arch/x86/kernel/cpu/mshyperv.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 646d192..4dab317 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
 	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
 		return false;
 
+	/*
+	 * Xen emulates Hyper-V to support enlightened Windows.
+	 * Check to see first if we are on a Xen Hypervisor.
+	 */
+	if (xen_cpuid_base())
+		return false;
+
 	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
 	      &eax, &hyp_signature[0], &hyp_signature[1], &hyp_signature[2]);
 
-- 
1.7.4.1

[tip:x86/hyperv] X86: Add a check to catch Xen emulation of Hyper-V

[tip-bot for K. Y. Srinivasan]

Commit-ID:  db34bbb767bdfa1ebed7214b876fe01c5b7ee457
Gitweb:     http://git.kernel.org/tip/db34bbb767bdfa1ebed7214b876fe01c5b7ee457
Author:     K. Y. Srinivasan <kys@microsoft.com>
AuthorDate: Sun, 3 Feb 2013 17:22:38 -0800
Committer:  H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Tue, 12 Feb 2013 16:27:03 -0800

X86: Add a check to catch Xen emulation of Hyper-V

Xen emulates Hyper-V to host enlightened Windows. Looks like this
emulation may be turned on by default even for Linux guests. Check and
fail Hyper-V detection if we are on Xen.

[ hpa: the problem here is that Xen doesn't emulate Hyper-V well
  enough, and if the Xen support isn't compiled in, we end up stubling
  over the Hyper-V emulation and try to activate it -- and it fails. ]

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Link: http://lkml.kernel.org/r/1359940959-32168-2-git-send-email-kys@microsoft.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
 arch/x86/kernel/cpu/mshyperv.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 646d192..4dab317 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
 	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
 		return false;
 
+	/*
+	 * Xen emulates Hyper-V to support enlightened Windows.
+	 * Check to see first if we are on a Xen Hypervisor.
+	 */
+	if (xen_cpuid_base())
+		return false;
+
 	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
 	      &eax, &hyp_signature[0], &hyp_signature[1], &hyp_signature[2]);
 

Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Michael S. Tsirkin]

On Sun, Feb 03, 2013 at 05:22:38PM -0800, K. Y. Srinivasan wrote:
> Xen emulates Hyper-V to host enlightened Windows. Looks like this
> emulation may be turned on by default even for Linux guests. Check and
> fail Hyper-V detection if we are on Xen.
> 
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>

I'm very curious what's the specific bug that is fixed here?
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?

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.

Could you enlighten me please? :)

> ---
>  arch/x86/kernel/cpu/mshyperv.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index 646d192..4dab317 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
>  	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
>  		return false;
>  
> +	/*
> +	 * Xen emulates Hyper-V to support enlightened Windows.
> +	 * Check to see first if we are on a Xen Hypervisor.
> +	 */
> +	if (xen_cpuid_base())
> +		return false;
> +
>  	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
>  	      &eax, &hyp_signature[0], &hyp_signature[1], &hyp_signature[2]);
>  
> -- 
> 1.7.4.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/

KVM "Hyper-V emulation" -- this can be related "Linux on Hyper-V" ? Or "KVM emulates Hyper-V" as "Hyper-V emulates Hyper-V" ? Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Victor Miasnikov]

Hi!

Short:

>> >> When KVM runs in Hyper-V emulation mode it expects to get Hyper-V hypercalls.
>> >>   Mixing KVM hypercalls and Hyper-V requires some tricks. It
VVM>> KVM  "Hyper-V emulation"   -- this can be related "Linux on Hyper-V" ?
> It's not related.

 Are You shue?
Xen-team _think_ too what is not related, but has non-100% _full_ emulation of Hyper-V and, as result, create problems

 Question is very simple:  Hyper-V users/sysadmins need wait patch a-la this:

==
KVM emulates Hyper-V to host enlightened Windows.

 . . .

[ hpa: the problem here is that KVM doesn't emulate Hyper-V well
  enough,  .  . ]

 . . .

+  * KVM emulates Hyper-V to support enlightened Windows.
+  * Check to see first if we are on a KVM Hypervisor.
+ if (KVM_cpuid_base())
+  return false;
 . . .
==

Or  "KVM emulates Hyper-V" as  "Hyper-V emulates Hyper-V" ?



--
Full:

----- Original Message ----- 
From: "Michael S. Tsirkin"
To: "K. Y. Srinivasan"
Cc:
Sent: Wednesday, April 17, 2013 10:06 AM
Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V


> On Sun, Feb 03, 2013 at 05:22:38PM -0800, K. Y. Srinivasan wrote:
>> Xen emulates Hyper-V to host enlightened Windows. Looks like this
>> emulation may be turned on by default even for Linux guests. Check and
>> fail Hyper-V detection if we are on Xen.
>>
>> Signed-off-by: K. Y. Srinivasan kys (at) microsoft.com
>
> I'm very curious what's the specific bug that is fixed here?
> 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?
>
> 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.
>
> Could you enlighten me please? :)

 Short history of question:

{{
==
> > And hypercall has its own set of problems with Windows guests.
> > When KVM runs in Hyper-V emulation mode it expects to get Hyper-V hypercalls.
> >   Mixing KVM hypercalls and Hyper-V requires some tricks. It
>
> Can't we simply register a hypercall ID range with Microsoft?
>
> > may also affect WHQLing Windows drivers since driver will talk to HW
> > bypassing Windows interfaces.
>
> Then the WHQL'ed driver doesn't support the PV MMIO hcall?
==

KVM  "Hyper-V emulation"   -- this can be related "Linux on Hyper-V" ?
}}

{{
>> >> When KVM runs in Hyper-V emulation mode it expects to get Hyper-V hypercalls.
>> >>   Mixing KVM hypercalls and Hyper-V requires some tricks. It
>> KVM  "Hyper-V emulation"   -- this can be related "Linux on Hyper-V" ?
> It's not related.

 Are You shue?
Xen-team _think_ too what is not related, but has non-100% _full_ emulation of Hyper-V and, as result, create problems:

==
Xen emulates Hyper-V to host enlightened Windows. Looks like this
emulation may be turned on by default even for Linux guests. Check and
fail Hyper-V detection if we are on Xen.

[ hpa: the problem here is that Xen doesn't emulate Hyper-V well
  enough, and if the Xen support isn't compiled in, we end up stubling
  over the Hyper-V emulation and try to activate it -- and it fails. ]

 . . .

+ /*
+  * Xen emulates Hyper-V to support enlightened Windows.
+  * Check to see first if we are on a Xen Hypervisor.
+  */
+ if (xen_cpuid_base())
+  return false;
+
==
}}


 Question is very simple:  Hyper-V users/sysadmins need wait patch a-la this:

==
KVM emulates Hyper-V to host enlightened Windows. Looks like this
emulation may be turned on by default even for Linux guests. Check and
fail Hyper-V detection if we are on KVM.

[ hpa: the problem here is that KVM doesn't emulate Hyper-V well
  enough, and if the KVM support isn't compiled in, we end up stubling
  over the Hyper-V emulation and try to activate it -- and it fails. ]

 . . .

+ /*
+  * KVM emulates Hyper-V to support enlightened Windows.
+  * Check to see first if we are on a KVM Hypervisor.
+  */
+ if (KVM_cpuid_base())
+  return false;
+
==


Or  "KVM emulates Hyper-V" as  "Hyper-V emulates Hyper-V" ?


Best regards, Victor Miasnikov
Blog:  http://vvm.blog.tut.by/

P.S.



----- Original Message ----- 
From: "Michael S. Tsirkin"
To: "Victor Miasnikov"
Sent: Wednesday, April 17, 2013 10:07 AM

I'm not sure what are we talking about then, but please
use the mailing list appropriate for the subject.


----- Original Message ----- 
From: "Victor Miasnikov" vvm (a) tut (dot) by
To: "Michael S. Tsirkin"
Cc: "KY Srinivasan"
Sent: Tuesday, April 16, 2013 9:36 AM
Subject: Are You shue what is 100% _full_ emulation of Hyper-V? Re: It's not related Re: KVM "Hyper-V emulation" -- this 
can be related "Linux on Hyper-V" ?

Hi!


>> >> When KVM runs in Hyper-V emulation mode it expects to get Hyper-V hypercalls.
>> >>   Mixing KVM hypercalls and Hyper-V requires some tricks. It
>> KVM  "Hyper-V emulation"   -- this can be related "Linux on Hyper-V" ?
> It's not related.

 Are You shue?
Xen-team _think_ too what is not related, but has non-100% _full_ emulation of Hyper-V and, as result, create problems:

==
Xen emulates Hyper-V to host enlightened Windows. Looks like this
emulation may be turned on by default even for Linux guests. Check and
fail Hyper-V detection if we are on Xen.

[ hpa: the problem here is that Xen doesn't emulate Hyper-V well
  enough, and if the Xen support isn't compiled in, we end up stubling
  over the Hyper-V emulation and try to activate it -- and it fails. ]

 . . .

+ /*
+  * Xen emulates Hyper-V to support enlightened Windows.
+  * Check to see first if we are on a Xen Hypervisor.
+  */
+ if (xen_cpuid_base())
+  return false;
+
==

 ( full see ib P.S.)

Best regards, Victor Miasnikov
Blog:  http://vvm.blog.tut.by/

P.S.


==
----- Original Message ----- 
From: "tip-bot for K. Y. Srinivasan"

 . . .

Sent: Wednesday, February 13, 2013 3:57 AM
Subject: [tip:x86/hyperv] X86: Add a check to catch Xen emulation of Hyper-V


Commit-ID:  db34bbb767bdfa1ebed7214b876fe01c5b7ee457
Gitweb:     http://git.kernel.org/tip/db34bbb767bdfa1ebed7214b876fe01c5b7ee457
Author:     K. Y. Srinivasan
AuthorDate: Sun, 3 Feb 2013 17:22:38 -0800
Committer:  H. Peter Anvin
CommitDate: Tue, 12 Feb 2013 16:27:03 -0800

X86: Add a check to catch Xen emulation of Hyper-V

Xen emulates Hyper-V to host enlightened Windows. Looks like this
emulation may be turned on by default even for Linux guests. Check and
fail Hyper-V detection if we are on Xen.

[ hpa: the problem here is that Xen doesn't emulate Hyper-V well
  enough, and if the Xen support isn't compiled in, we end up stubling
  over the Hyper-V emulation and try to activate it -- and it fails. ]

Signed-off-by: K. Y. Srinivasan
Link: http://lkml.kernel.org/r/1359940959-32168-2-git-send-email-kys@microsoft.com
Signed-off-by: H. Peter Anvin
---
 arch/x86/kernel/cpu/mshyperv.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 646d192..4dab317 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
  if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
   return false;

+ /*
+  * Xen emulates Hyper-V to support enlightened Windows.
+  * Check to see first if we are on a Xen Hypervisor.
+  */
+ if (xen_cpuid_base())
+  return false;
+
  cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
        &eax, &hyp_signature[0], &hyp_signature[1], &hyp_signature[2]);

--
==







----- Original Message ----- 
From: "Michael S. Tsirkin"
To: "Victor Miasnikov" vvm (a) tut (dot) by
Sent: Tuesday, April 16, 2013 1:11 AM
Subject: Re: KVM "Hyper-V emulation" -- this can be related "Linux on Hyper-V" ? Fw: When KVM runs in Hyper-V emulation
mode it expects to get Hyper-V hypercalls.


> On Mon, Apr 15, 2013 at 04:00:34PM +0300, Victor Miasnikov wrote:
>>
>> ==
>> >> And hypercall has its own set of problems with Windows guests.
>> >> When KVM runs in Hyper-V emulation mode it expects to get Hyper-V hypercalls.
>> >>   Mixing KVM hypercalls and Hyper-V requires some tricks. It
>> >
>> >Can't we simply register a hypercall ID range with Microsoft?
>> >
>> >> may also affect WHQLing Windows drivers since driver will talk to HW
>> >> bypassing Windows interfaces.
>> >
>> >Then the WHQL'ed driver doesn't support the PV MMIO hcall?
>> ==
>>
>> KVM  "Hyper-V emulation"   -- this can be related "Linux on Hyper-V" ?
>>
>>
>
> It's not related.





----- Original Message ----- 
From: "Victor Miasnikov" vvm (a) tut (dot) by
To: "Michael S. Tsirkin"
Sent: Monday, April 15, 2013 4:00 PM
Subject: KVM "Hyper-V emulation" -- this can be related "Linux on Hyper-V" ? Fw: When KVM runs in Hyper-V emulation mode
it expects to get Hyper-V hypercalls.


Hi!


==
> > And hypercall has its own set of problems with Windows guests.
> > When KVM runs in Hyper-V emulation mode it expects to get Hyper-V hypercalls.
> >   Mixing KVM hypercalls and Hyper-V requires some tricks. It
>
> Can't we simply register a hypercall ID range with Microsoft?
>
> > may also affect WHQLing Windows drivers since driver will talk to HW
> > bypassing Windows interfaces.
>
> Then the WHQL'ed driver doesn't support the PV MMIO hcall?
==

KVM  "Hyper-V emulation"   -- this can be related "Linux on Hyper-V" ?


Best regards, Victor Miasnikov
Blog:  http://vvm.blog.tut.by/

Re: KVM "Hyper-V emulation" -- this can be related "Linux on Hyper-V" ? Or "KVM emulates Hyper-V" as "Hyper-V emulates Hyper-V" ? Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Michael S. Tsirkin]

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:
> 
> ==
> KVM emulates Hyper-V to host enlightened Windows. Looks like this
> emulation may be turned on by default even for Linux guests. Check and
> fail Hyper-V detection if we are on KVM.

> [ hpa: the problem here is that KVM doesn't emulate Hyper-V well
>  enough, and if the KVM support isn't compiled in, we end up stubling
>  over the Hyper-V emulation and try to activate it -- and it fails. ]
> 
> . . .

What's emulated not well enough?

> + /*
> +  * KVM emulates Hyper-V to support enlightened Windows.
> +  * Check to see first if we are on a KVM Hypervisor.
> +  */

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.

> + if (KVM_cpuid_base())
> +  return false;
> +
> ==
> 
> 
> Or  "KVM emulates Hyper-V" as  "Hyper-V emulates Hyper-V" ?
> 
> 
> Best regards, Victor Miasnikov
> Blog:  http://vvm.blog.tut.by/
> 
> P.S.

No.  You are using Hyper-V, not the KVM emulation of it.  No patches
dealing with this emulation should have any effect on you.

-- 
MST

Re: KVM "Hyper-V emulation" -- this can be related "Linux on Hyper-V" ? Or "KVM emulates Hyper-V" as "Hyper-V emulates Hyper-V" ? Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Jan Beulich]

>>> On 17.04.13 at 12:16, "Michael S. Tsirkin" <mst@redhat.com> 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.

Jan

Re: KVM "Hyper-V emulation" -- this can be related "Linux on Hyper-V" ? Or "KVM emulates Hyper-V" as "Hyper-V emulates Hyper-V" ? Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Michael S. Tsirkin]

On Wed, Apr 17, 2013 at 01:12:37PM +0100, Jan Beulich wrote:
> >>> On 17.04.13 at 12:16, "Michael S. Tsirkin" <mst@redhat.com> 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,

Fact is that this patch changed the guest/hypervisor interface which
should not be done lightly. We don't know all uses that Linux is put
to.  I gave what seems, to me, like a perfectly valid reason to use
hyper-v emulation with Linux guests, which you snipped out :) Below is
a scanario that will now be broken:
	>>>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,
There could be others.

> such guests could use the native hypervisor interface with much
> greater benefit.

Why not disable the emulation in the hypervisor?  What overriding the
hypervisor will lead to, is hypervisors will try harder and mask their
real identity.  No one will win in this arms race.

> And second, there reportedly are features of (newer?) Hyper-V
> that some emulation may not provide, but that are also not easily
> detectable.
> 
> Jan

Could you be more explicit please?  What are these features?  How does a
windows guest able to use them if they are both new and not detectable?
Why not just fix the emulation?  How will Linux use the new features
when e.g. Xen adds them?

-- 
MST

Re: KVM "Hyper-V emulation" -- this can be related "Linux on Hyper-V" ? Or "KVM emulates Hyper-V" as "Hyper-V emulates Hyper-V" ? Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Michael S. Tsirkin]

On Wed, Apr 17, 2013 at 04:03:08PM +0300, Victor M. wrote:
> Hi!
> 
> 2013/4/17 Jan Beulich
> 
>     >>> 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.
>    
> 
> 
> 
> Yes
>  
> +
>  
> 
> > 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.
> 
> 
>  This is _positive_ variant of possible future,
> but on _practic_ very often we need prevent _negative_ variant of possible
> future

I don't really know what this means.

> 
> >> ==
> >> + /*
> >> +  *
> 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.
> >
> 
> 
>  Even if guest ( i.e. Virtual Computer) contain Linux OS ?

Why not?  If you don't want the hypervisor to emulate hyper-v, just
don't tell it to emulate 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?
> >
> 
>  In case of XEN variant non-full-emulation_of_Hyper-V , IMHO :
> 
> {{
> ----- Original Message -----
> From: "Victor Miasnikov"
> To: "Michael S. Tsirkin"
> Sent: Wednesday, April 17, 2013 12:41 PM
> Subject: IMHO, XEN emulation of Hyper-V not contain needed clocksource for
> Lunux guest Re: [PATCH 2/3] X86: Add a check
> to catch Xen emulation of Hyper-V
> 
> Hi!
> 
> > 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.
> 
>  As I undestand, XEN emulation of Hyper-V not contain  needed clocksource for
> Lunux guest ( virtual computers)
> 
> I.e. Linux VM "think" what is running on Hyper-V host call
> clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100)
> and a-la BSOD or vica verse . . .
> 
> 
> > 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?
> 
> 
>  IMHO, this related to:
> 
> - clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
> + if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
> +  clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
> 
> 
>  See
> 
> https://lkml.org/lkml/2013/2/12/623
> ==
>             Date Tue, 12 Feb 2013 16:56:07 -0800
>             From tip-bot for Olaf Hering
>             Subject [tip:x86/hyperv] x86: Hyper-V: register clocksource only if
> its advertised
> 
>  . . .
> 
> ==
> 
> 
> 
> Best regards, Victor Miasnikov
> }}
> 
> 
> 
> 
> 
> Best regards, Victor Miasnikov
> Blog:  http://vvm.blog.tut.by/

Looks like a counter-example to me.

Apparently a Linux guest bug was found and fixed exactly because we
trust the hypervisor.  If it wasn't, and if in the future hyper-v hosts
clear this feature bit, Linux will be broken.

-- 
MST

Re: KVM "Hyper-V emulation" -- this can be related "Linux on Hyper-V" ? Or "KVM emulates Hyper-V" as "Hyper-V emulates Hyper-V" ? Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Victor Miasnikov]

Hi!

>> This is _positive_ variant of possible future,
>> but on _practic_ very often we need prevent _negative_ variant of possible
>> future
> 
> I don't really know what this means.
>

 On practic: this means, that need test with KVM "Hyper-V emulation" not only Windows guest, but _all_ Linux guest

_all_ Linux need read -- not only RHEL, but 
-- Debian 7.X ( kernell v3.2 with own hotfixes set) , 
-- Ubuntu 12.04 LTS ( kernell v3.2 with hotfixes)
-- Ubuntu 12.04.03 LTS ( kernell v3.5 with hotfixes)
-- Ubuntu 12.10 ( kernell v3.5 with hotfixes)
-- Linuxes with kernel v3.6 / or v3.7
-- Linuxes with latest stable kernel v3.8 ( for example Arch Linux)
-- other possible variants

Best regards, Victor Miasnikov
Blog:  http://vvm.blog.tut.by/


P.S.
  I'm personal not want, what KVM "Hyper-V emulation" initiative stopped implemented
If it work as need -- this is very good

RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[KY Srinivasan]

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Wednesday, April 17, 2013 3:06 AM
> To: KY Srinivasan
> Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> JBeulich@suse.com; bp@alien8.de
> Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> 
> On Sun, Feb 03, 2013 at 05:22:38PM -0800, K. Y. Srinivasan wrote:
> > Xen emulates Hyper-V to host enlightened Windows. Looks like this
> > emulation may be turned on by default even for Linux guests. Check and
> > fail Hyper-V detection if we are on Xen.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> 
> I'm very curious what's the specific bug that is fixed here?
> 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?
> 
> 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.
> 
> Could you enlighten me please? :)

Michael,

If I recall correctly, the issue here was that Xen was enabling Hyper-V emulation un-conditionally even for Linux guests. Clearly, this was not the intention to begin with. This check was added to ensure that while hosting Linux we would not un-intentionally enable Hyper-V emulation in Xen. Not all Hyper-V features are tagged with a CPUID feature bit and so it was agreed that it would be better to disable Hyper-V emulation when hosting Linux on Xen.

Regards,

K. Y
> 
> > ---
> >  arch/x86/kernel/cpu/mshyperv.c |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> b/arch/x86/kernel/cpu/mshyperv.c
> > index 646d192..4dab317 100644
> > --- a/arch/x86/kernel/cpu/mshyperv.c
> > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > @@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
> >  	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> >  		return false;
> >
> > +	/*
> > +	 * Xen emulates Hyper-V to support enlightened Windows.
> > +	 * Check to see first if we are on a Xen Hypervisor.
> > +	 */
> > +	if (xen_cpuid_base())
> > +		return false;
> > +
> >  	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
> >  	      &eax, &hyp_signature[0], &hyp_signature[1], &hyp_signature[2]);
> >
> > --
> > 1.7.4.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/
> 

Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Michael S. Tsirkin]

On Wed, Apr 17, 2013 at 01:20:58PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > Sent: Wednesday, April 17, 2013 3:06 AM
> > To: KY Srinivasan
> > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > JBeulich@suse.com; bp@alien8.de
> > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > 
> > On Sun, Feb 03, 2013 at 05:22:38PM -0800, K. Y. Srinivasan wrote:
> > > Xen emulates Hyper-V to host enlightened Windows. Looks like this
> > > emulation may be turned on by default even for Linux guests. Check and
> > > fail Hyper-V detection if we are on Xen.
> > >
> > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > 
> > I'm very curious what's the specific bug that is fixed here?
> > 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?
> > 
> > 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.
> > 
> > Could you enlighten me please? :)
> 
> Michael,
> 
> If I recall correctly, the issue here was that Xen was enabling
> Hyper-V emulation un-conditionally even for Linux guests.

Okay so basically some Xen specific strangeness.

> Clearly,
> this was not the intention to begin with. This check was added to
> ensure that while hosting Linux we would not un-intentionally enable
> Hyper-V emulation in Xen.

What if you want to intentionally enable Hyper-V emulation in Xen?
There's no way to do this now, right?

> Not all Hyper-V features are tagged with a
> CPUID feature bit and so it was agreed that it would be better to
> disable Hyper-V emulation when hosting Linux on Xen.
> 
> Regards,
> 
> K. Y

I was just asking whether there are any specific examples of a bug
or is this change done just in case?

> > 
> > > ---
> > >  arch/x86/kernel/cpu/mshyperv.c |    7 +++++++
> > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> > b/arch/x86/kernel/cpu/mshyperv.c
> > > index 646d192..4dab317 100644
> > > --- a/arch/x86/kernel/cpu/mshyperv.c
> > > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > > @@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
> > >  	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > >  		return false;
> > >
> > > +	/*
> > > +	 * Xen emulates Hyper-V to support enlightened Windows.
> > > +	 * Check to see first if we are on a Xen Hypervisor.
> > > +	 */
> > > +	if (xen_cpuid_base())
> > > +		return false;
> > > +
> > >  	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
> > >  	      &eax, &hyp_signature[0], &hyp_signature[1], &hyp_signature[2]);
> > >
> > > --
> > > 1.7.4.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/
> > 
> 

RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[KY Srinivasan]

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Wednesday, April 17, 2013 8:49 AM
> To: KY Srinivasan
> Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> JBeulich@suse.com; bp@alien8.de
> Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> 
> On Wed, Apr 17, 2013 at 01:20:58PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > Sent: Wednesday, April 17, 2013 3:06 AM
> > > To: KY Srinivasan
> > > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-
> kernel@vger.kernel.org;
> > > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > > JBeulich@suse.com; bp@alien8.de
> > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > >
> > > On Sun, Feb 03, 2013 at 05:22:38PM -0800, K. Y. Srinivasan wrote:
> > > > Xen emulates Hyper-V to host enlightened Windows. Looks like this
> > > > emulation may be turned on by default even for Linux guests. Check and
> > > > fail Hyper-V detection if we are on Xen.
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > >
> > > I'm very curious what's the specific bug that is fixed here?
> > > 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?
> > >
> > > 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.
> > >
> > > Could you enlighten me please? :)
> >
> > Michael,
> >
> > If I recall correctly, the issue here was that Xen was enabling
> > Hyper-V emulation un-conditionally even for Linux guests.
> 
> Okay so basically some Xen specific strangeness.
> 
> > Clearly,
> > this was not the intention to begin with. This check was added to
> > ensure that while hosting Linux we would not un-intentionally enable
> > Hyper-V emulation in Xen.
> 
> What if you want to intentionally enable Hyper-V emulation in Xen?
> There's no way to do this now, right?
> 
> > Not all Hyper-V features are tagged with a
> > CPUID feature bit and so it was agreed that it would be better to
> > disable Hyper-V emulation when hosting Linux on Xen.
> >
> > Regards,
> >
> > K. Y
> 
> I was just asking whether there are any specific examples of a bug
> or is this change done just in case?

Ideally, if Hyper-V could be emulated in a plug compatible way, in that the guest would not know
the difference as to whether Hyper-V was being emulated or indeed it was Hyper-V underneath, I would agree with you.
Even in this case, I would argue that we would somehow give preference to the native implementation rather
than the emulated environment. Having done the initial emulation of Hyper-V on Xen, I know the current emulation of 
Hyper-V is restricted to emulating a few features advertised via the CPUID bits. If I recall correctly, Xen did not implement
the enlightened TLB flush scheme. Furthermore, none of the Hyper-V emulations implement the I/O related infrastructure.
For Linux to run efficiently on Hyper-V, the I/O paths are significantly more important than what Hyper-V emulation there is
in Xen and I suspect in KVM. So, I don't think we want to run Linux on Xen/KVM that is emulating Hyper-V (cpuids).
The specific case I ran into that required this patch was when I moved the VMBUS interrupts to be delivered via a special
hypervisor vector (to support full interrupt distribution amongst all VCPUs in the guest). This feature is not tagged in the CPUID
feature bits and without this check, I would install an interrupt handler for the hypervisor vector that clearly did not make
any sense in anything other than Hyper-V. I suspect there will be more such situations as we go forward.

Regards,

K. Y 
> 
> > >
> > > > ---
> > > >  arch/x86/kernel/cpu/mshyperv.c |    7 +++++++
> > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> > > b/arch/x86/kernel/cpu/mshyperv.c
> > > > index 646d192..4dab317 100644
> > > > --- a/arch/x86/kernel/cpu/mshyperv.c
> > > > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > > > @@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
> > > >  	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > > >  		return false;
> > > >
> > > > +	/*
> > > > +	 * Xen emulates Hyper-V to support enlightened Windows.
> > > > +	 * Check to see first if we are on a Xen Hypervisor.
> > > > +	 */
> > > > +	if (xen_cpuid_base())
> > > > +		return false;
> > > > +
> > > >  	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
> > > >  	      &eax, &hyp_signature[0], &hyp_signature[1], &hyp_signature[2]);
> > > >
> > > > --
> > > > 1.7.4.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/
> > >
> >
> 

Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Michael S. Tsirkin]

On Wed, Apr 17, 2013 at 02:12:12PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > Sent: Wednesday, April 17, 2013 8:49 AM
> > To: KY Srinivasan
> > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > JBeulich@suse.com; bp@alien8.de
> > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > 
> > On Wed, Apr 17, 2013 at 01:20:58PM +0000, KY Srinivasan wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > > Sent: Wednesday, April 17, 2013 3:06 AM
> > > > To: KY Srinivasan
> > > > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-
> > kernel@vger.kernel.org;
> > > > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > > > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > > > JBeulich@suse.com; bp@alien8.de
> > > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > > >
> > > > On Sun, Feb 03, 2013 at 05:22:38PM -0800, K. Y. Srinivasan wrote:
> > > > > Xen emulates Hyper-V to host enlightened Windows. Looks like this
> > > > > emulation may be turned on by default even for Linux guests. Check and
> > > > > fail Hyper-V detection if we are on Xen.
> > > > >
> > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > >
> > > > I'm very curious what's the specific bug that is fixed here?
> > > > 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?
> > > >
> > > > 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.
> > > >
> > > > Could you enlighten me please? :)
> > >
> > > Michael,
> > >
> > > If I recall correctly, the issue here was that Xen was enabling
> > > Hyper-V emulation un-conditionally even for Linux guests.
> > 
> > Okay so basically some Xen specific strangeness.
> > 
> > > Clearly,
> > > this was not the intention to begin with. This check was added to
> > > ensure that while hosting Linux we would not un-intentionally enable
> > > Hyper-V emulation in Xen.
> > 
> > What if you want to intentionally enable Hyper-V emulation in Xen?
> > There's no way to do this now, right?
> > 
> > > Not all Hyper-V features are tagged with a
> > > CPUID feature bit and so it was agreed that it would be better to
> > > disable Hyper-V emulation when hosting Linux on Xen.
> > >
> > > Regards,
> > >
> > > K. Y
> > 
> > I was just asking whether there are any specific examples of a bug
> > or is this change done just in case?
> 
> Ideally, if Hyper-V could be emulated in a plug compatible way, in that the guest would not know
> the difference as to whether Hyper-V was being emulated or indeed it was Hyper-V underneath, I would agree with you.
> Even in this case, I would argue that we would somehow give preference to the native implementation rather
> than the emulated environment. Having done the initial emulation of Hyper-V on Xen, I know the current emulation of 
> Hyper-V is restricted to emulating a few features advertised via the CPUID bits. If I recall correctly, Xen did not implement
> the enlightened TLB flush scheme. Furthermore, none of the Hyper-V emulations implement the I/O related infrastructure.
> For Linux to run efficiently on Hyper-V, the I/O paths are significantly more important than what Hyper-V emulation there is
> in Xen and I suspect in KVM. So, I don't think we want to run Linux on Xen/KVM that is emulating Hyper-V (cpuids).

No, it's a Xen specific bug.  KVM in a hyper-v mode still emulates PCI
so can still use KVM PV devices which are all PCI devices. So there's no problem there.

Also, why override this in the guest? With time Xen hyper-v emulation
might improve, meanwhile it's always possible to disable this in
the hypervisor.

> The specific case I ran into that required this patch was when I moved the VMBUS interrupts to be delivered via a special
> hypervisor vector (to support full interrupt distribution amongst all VCPUs in the guest). This feature is not tagged in the CPUID
> feature bits and without this check, I would install an interrupt handler for the hypervisor vector that clearly did not make
> any sense in anything other than Hyper-V. I suspect there will be more such situations as we go forward.
> 
> Regards,
> 
> K. Y 

Why? Because there's no VMBUS on Xen? So check whether VMBUS exists?

> > 
> > > >
> > > > > ---
> > > > >  arch/x86/kernel/cpu/mshyperv.c |    7 +++++++
> > > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> > > > b/arch/x86/kernel/cpu/mshyperv.c
> > > > > index 646d192..4dab317 100644
> > > > > --- a/arch/x86/kernel/cpu/mshyperv.c
> > > > > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > > > > @@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
> > > > >  	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > > > >  		return false;
> > > > >
> > > > > +	/*
> > > > > +	 * Xen emulates Hyper-V to support enlightened Windows.
> > > > > +	 * Check to see first if we are on a Xen Hypervisor.
> > > > > +	 */
> > > > > +	if (xen_cpuid_base())
> > > > > +		return false;
> > > > > +
> > > > >  	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
> > > > >  	      &eax, &hyp_signature[0], &hyp_signature[1], &hyp_signature[2]);
> > > > >
> > > > > --
> > > > > 1.7.4.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/
> > > >
> > >
> > 
> 

RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[KY Srinivasan]

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Wednesday, April 17, 2013 9:25 AM
> To: KY Srinivasan
> Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> JBeulich@suse.com; bp@alien8.de
> Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> 
> On Wed, Apr 17, 2013 at 02:12:12PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > Sent: Wednesday, April 17, 2013 8:49 AM
> > > To: KY Srinivasan
> > > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-
> kernel@vger.kernel.org;
> > > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > > JBeulich@suse.com; bp@alien8.de
> > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > >
> > > On Wed, Apr 17, 2013 at 01:20:58PM +0000, KY Srinivasan wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > > > Sent: Wednesday, April 17, 2013 3:06 AM
> > > > > To: KY Srinivasan
> > > > > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-
> > > kernel@vger.kernel.org;
> > > > > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > > > > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > > > > JBeulich@suse.com; bp@alien8.de
> > > > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of
> Hyper-V
> > > > >
> > > > > On Sun, Feb 03, 2013 at 05:22:38PM -0800, K. Y. Srinivasan wrote:
> > > > > > Xen emulates Hyper-V to host enlightened Windows. Looks like this
> > > > > > emulation may be turned on by default even for Linux guests. Check
> and
> > > > > > fail Hyper-V detection if we are on Xen.
> > > > > >
> > > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > >
> > > > > I'm very curious what's the specific bug that is fixed here?
> > > > > 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?
> > > > >
> > > > > 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.
> > > > >
> > > > > Could you enlighten me please? :)
> > > >
> > > > Michael,
> > > >
> > > > If I recall correctly, the issue here was that Xen was enabling
> > > > Hyper-V emulation un-conditionally even for Linux guests.
> > >
> > > Okay so basically some Xen specific strangeness.
> > >
> > > > Clearly,
> > > > this was not the intention to begin with. This check was added to
> > > > ensure that while hosting Linux we would not un-intentionally enable
> > > > Hyper-V emulation in Xen.
> > >
> > > What if you want to intentionally enable Hyper-V emulation in Xen?
> > > There's no way to do this now, right?
> > >
> > > > Not all Hyper-V features are tagged with a
> > > > CPUID feature bit and so it was agreed that it would be better to
> > > > disable Hyper-V emulation when hosting Linux on Xen.
> > > >
> > > > Regards,
> > > >
> > > > K. Y
> > >
> > > I was just asking whether there are any specific examples of a bug
> > > or is this change done just in case?
> >
> > Ideally, if Hyper-V could be emulated in a plug compatible way, in that the guest
> would not know
> > the difference as to whether Hyper-V was being emulated or indeed it was
> Hyper-V underneath, I would agree with you.
> > Even in this case, I would argue that we would somehow give preference to the
> native implementation rather
> > than the emulated environment. Having done the initial emulation of Hyper-V
> on Xen, I know the current emulation of
> > Hyper-V is restricted to emulating a few features advertised via the CPUID bits.
> If I recall correctly, Xen did not implement
> > the enlightened TLB flush scheme. Furthermore, none of the Hyper-V
> emulations implement the I/O related infrastructure.
> > For Linux to run efficiently on Hyper-V, the I/O paths are significantly more
> important than what Hyper-V emulation there is
> > in Xen and I suspect in KVM. So, I don't think we want to run Linux on Xen/KVM
> that is emulating Hyper-V (cpuids).
> 
> No, it's a Xen specific bug.  KVM in a hyper-v mode still emulates PCI
> so can still use KVM PV devices which are all PCI devices. So there's no problem
> there.

Even Xen does not have a problem here; Xen would install its PV drivers in the guest.
So, the I/O infrastructure that would be installed in the guest would be based on the 
host.
> 
> Also, why override this in the guest? With time Xen hyper-v emulation
> might improve, meanwhile it's always possible to disable this in
> the hypervisor.
> 
> > The specific case I ran into that required this patch was when I moved the
> VMBUS interrupts to be delivered via a special
> > hypervisor vector (to support full interrupt distribution amongst all VCPUs in
> the guest). This feature is not tagged in the CPUID
> > feature bits and without this check, I would install an interrupt handler for the
> hypervisor vector that clearly did not make
> > any sense in anything other than Hyper-V. I suspect there will be more such
> situations as we go forward.
> >
> > Regards,
> >
> > K. Y
> 
> Why? Because there's no VMBUS on Xen? So check whether VMBUS exists?
On Linux, Hyper-V detection is used to load hyper-V related drivers (VMBUS etc.). For the case in
point, it was not clear to me how I could install the vmbus interrupt handler in a way that would
make sense when Xen was unconditionally emulating Hyper-V. 

Regards,

K. Y
> 
> > >
> > > > >
> > > > > > ---
> > > > > >  arch/x86/kernel/cpu/mshyperv.c |    7 +++++++
> > > > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> > > > > b/arch/x86/kernel/cpu/mshyperv.c
> > > > > > index 646d192..4dab317 100644
> > > > > > --- a/arch/x86/kernel/cpu/mshyperv.c
> > > > > > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > > > > > @@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
> > > > > >  	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > > > > >  		return false;
> > > > > >
> > > > > > +	/*
> > > > > > +	 * Xen emulates Hyper-V to support enlightened Windows.
> > > > > > +	 * Check to see first if we are on a Xen Hypervisor.
> > > > > > +	 */
> > > > > > +	if (xen_cpuid_base())
> > > > > > +		return false;
> > > > > > +
> > > > > >  	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
> > > > > >  	      &eax, &hyp_signature[0], &hyp_signature[1],
> &hyp_signature[2]);
> > > > > >
> > > > > > --
> > > > > > 1.7.4.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/
> > > > >
> > > >
> > >
> >
> 

Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Michael S. Tsirkin]

On Wed, Apr 17, 2013 at 02:34:57PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > Sent: Wednesday, April 17, 2013 9:25 AM
> > To: KY Srinivasan
> > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > JBeulich@suse.com; bp@alien8.de
> > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > 
> > On Wed, Apr 17, 2013 at 02:12:12PM +0000, KY Srinivasan wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > > Sent: Wednesday, April 17, 2013 8:49 AM
> > > > To: KY Srinivasan
> > > > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-
> > kernel@vger.kernel.org;
> > > > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > > > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > > > JBeulich@suse.com; bp@alien8.de
> > > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > > >
> > > > On Wed, Apr 17, 2013 at 01:20:58PM +0000, KY Srinivasan wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > > > > Sent: Wednesday, April 17, 2013 3:06 AM
> > > > > > To: KY Srinivasan
> > > > > > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-
> > > > kernel@vger.kernel.org;
> > > > > > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > > > > > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > > > > > JBeulich@suse.com; bp@alien8.de
> > > > > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of
> > Hyper-V
> > > > > >
> > > > > > On Sun, Feb 03, 2013 at 05:22:38PM -0800, K. Y. Srinivasan wrote:
> > > > > > > Xen emulates Hyper-V to host enlightened Windows. Looks like this
> > > > > > > emulation may be turned on by default even for Linux guests. Check
> > and
> > > > > > > fail Hyper-V detection if we are on Xen.
> > > > > > >
> > > > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > >
> > > > > > I'm very curious what's the specific bug that is fixed here?
> > > > > > 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?
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > Could you enlighten me please? :)
> > > > >
> > > > > Michael,
> > > > >
> > > > > If I recall correctly, the issue here was that Xen was enabling
> > > > > Hyper-V emulation un-conditionally even for Linux guests.
> > > >
> > > > Okay so basically some Xen specific strangeness.
> > > >
> > > > > Clearly,
> > > > > this was not the intention to begin with. This check was added to
> > > > > ensure that while hosting Linux we would not un-intentionally enable
> > > > > Hyper-V emulation in Xen.
> > > >
> > > > What if you want to intentionally enable Hyper-V emulation in Xen?
> > > > There's no way to do this now, right?
> > > >
> > > > > Not all Hyper-V features are tagged with a
> > > > > CPUID feature bit and so it was agreed that it would be better to
> > > > > disable Hyper-V emulation when hosting Linux on Xen.
> > > > >
> > > > > Regards,
> > > > >
> > > > > K. Y
> > > >
> > > > I was just asking whether there are any specific examples of a bug
> > > > or is this change done just in case?
> > >
> > > Ideally, if Hyper-V could be emulated in a plug compatible way, in that the guest
> > would not know
> > > the difference as to whether Hyper-V was being emulated or indeed it was
> > Hyper-V underneath, I would agree with you.
> > > Even in this case, I would argue that we would somehow give preference to the
> > native implementation rather
> > > than the emulated environment. Having done the initial emulation of Hyper-V
> > on Xen, I know the current emulation of
> > > Hyper-V is restricted to emulating a few features advertised via the CPUID bits.
> > If I recall correctly, Xen did not implement
> > > the enlightened TLB flush scheme. Furthermore, none of the Hyper-V
> > emulations implement the I/O related infrastructure.
> > > For Linux to run efficiently on Hyper-V, the I/O paths are significantly more
> > important than what Hyper-V emulation there is
> > > in Xen and I suspect in KVM. So, I don't think we want to run Linux on Xen/KVM
> > that is emulating Hyper-V (cpuids).
> > 
> > No, it's a Xen specific bug.  KVM in a hyper-v mode still emulates PCI
> > so can still use KVM PV devices which are all PCI devices. So there's no problem
> > there.
> 
> Even Xen does not have a problem here; Xen would install its PV drivers in the guest.
> So, the I/O infrastructure that would be installed in the guest would be based on the 
> host.
> > 
> > Also, why override this in the guest? With time Xen hyper-v emulation
> > might improve, meanwhile it's always possible to disable this in
> > the hypervisor.
> > 
> > > The specific case I ran into that required this patch was when I moved the
> > VMBUS interrupts to be delivered via a special
> > > hypervisor vector (to support full interrupt distribution amongst all VCPUs in
> > the guest). This feature is not tagged in the CPUID
> > > feature bits and without this check, I would install an interrupt handler for the
> > hypervisor vector that clearly did not make
> > > any sense in anything other than Hyper-V. I suspect there will be more such
> > situations as we go forward.
> > >
> > > Regards,
> > >
> > > K. Y
> > 
> > Why? Because there's no VMBUS on Xen? So check whether VMBUS exists?
> On Linux, Hyper-V detection is used to load hyper-V related drivers (VMBUS etc.). For the case in
> point, it was not clear to me how I could install the vmbus interrupt handler in a way that would
> make sense when Xen was unconditionally emulating Hyper-V. 
> 
> Regards,
> 
> K. Y

For example, check whether there is anything on the vmbus?

> > 
> > > >
> > > > > >
> > > > > > > ---
> > > > > > >  arch/x86/kernel/cpu/mshyperv.c |    7 +++++++
> > > > > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > > > > >
> > > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> > > > > > b/arch/x86/kernel/cpu/mshyperv.c
> > > > > > > index 646d192..4dab317 100644
> > > > > > > --- a/arch/x86/kernel/cpu/mshyperv.c
> > > > > > > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > > > > > > @@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
> > > > > > >  	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > > > > > >  		return false;
> > > > > > >
> > > > > > > +	/*
> > > > > > > +	 * Xen emulates Hyper-V to support enlightened Windows.
> > > > > > > +	 * Check to see first if we are on a Xen Hypervisor.
> > > > > > > +	 */
> > > > > > > +	if (xen_cpuid_base())
> > > > > > > +		return false;
> > > > > > > +
> > > > > > >  	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
> > > > > > >  	      &eax, &hyp_signature[0], &hyp_signature[1],
> > &hyp_signature[2]);
> > > > > > >
> > > > > > > --
> > > > > > > 1.7.4.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/
> > > > > >
> > > > >
> > > >
> > >
> > 
> 

RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[KY Srinivasan]

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Wednesday, April 17, 2013 9:49 AM
> To: KY Srinivasan
> Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> JBeulich@suse.com; bp@alien8.de
> Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> 
> On Wed, Apr 17, 2013 at 02:34:57PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > Sent: Wednesday, April 17, 2013 9:25 AM
> > > To: KY Srinivasan
> > > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-
> kernel@vger.kernel.org;
> > > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > > JBeulich@suse.com; bp@alien8.de
> > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > >
> > > On Wed, Apr 17, 2013 at 02:12:12PM +0000, KY Srinivasan wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > > > Sent: Wednesday, April 17, 2013 8:49 AM
> > > > > To: KY Srinivasan
> > > > > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-
> > > kernel@vger.kernel.org;
> > > > > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > > > > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > > > > JBeulich@suse.com; bp@alien8.de
> > > > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of
> Hyper-V
> > > > >
> > > > > On Wed, Apr 17, 2013 at 01:20:58PM +0000, KY Srinivasan wrote:
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > > > > > Sent: Wednesday, April 17, 2013 3:06 AM
> > > > > > > To: KY Srinivasan
> > > > > > > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-
> > > > > kernel@vger.kernel.org;
> > > > > > > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > > > > > > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > > > > > > JBeulich@suse.com; bp@alien8.de
> > > > > > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of
> > > Hyper-V
> > > > > > >
> > > > > > > On Sun, Feb 03, 2013 at 05:22:38PM -0800, K. Y. Srinivasan wrote:
> > > > > > > > Xen emulates Hyper-V to host enlightened Windows. Looks like this
> > > > > > > > emulation may be turned on by default even for Linux guests. Check
> > > and
> > > > > > > > fail Hyper-V detection if we are on Xen.
> > > > > > > >
> > > > > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > > >
> > > > > > > I'm very curious what's the specific bug that is fixed here?
> > > > > > > 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?
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > Could you enlighten me please? :)
> > > > > >
> > > > > > Michael,
> > > > > >
> > > > > > If I recall correctly, the issue here was that Xen was enabling
> > > > > > Hyper-V emulation un-conditionally even for Linux guests.
> > > > >
> > > > > Okay so basically some Xen specific strangeness.
> > > > >
> > > > > > Clearly,
> > > > > > this was not the intention to begin with. This check was added to
> > > > > > ensure that while hosting Linux we would not un-intentionally enable
> > > > > > Hyper-V emulation in Xen.
> > > > >
> > > > > What if you want to intentionally enable Hyper-V emulation in Xen?
> > > > > There's no way to do this now, right?
> > > > >
> > > > > > Not all Hyper-V features are tagged with a
> > > > > > CPUID feature bit and so it was agreed that it would be better to
> > > > > > disable Hyper-V emulation when hosting Linux on Xen.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > K. Y
> > > > >
> > > > > I was just asking whether there are any specific examples of a bug
> > > > > or is this change done just in case?
> > > >
> > > > Ideally, if Hyper-V could be emulated in a plug compatible way, in that the
> guest
> > > would not know
> > > > the difference as to whether Hyper-V was being emulated or indeed it was
> > > Hyper-V underneath, I would agree with you.
> > > > Even in this case, I would argue that we would somehow give preference to
> the
> > > native implementation rather
> > > > than the emulated environment. Having done the initial emulation of
> Hyper-V
> > > on Xen, I know the current emulation of
> > > > Hyper-V is restricted to emulating a few features advertised via the CPUID
> bits.
> > > If I recall correctly, Xen did not implement
> > > > the enlightened TLB flush scheme. Furthermore, none of the Hyper-V
> > > emulations implement the I/O related infrastructure.
> > > > For Linux to run efficiently on Hyper-V, the I/O paths are significantly more
> > > important than what Hyper-V emulation there is
> > > > in Xen and I suspect in KVM. So, I don't think we want to run Linux on
> Xen/KVM
> > > that is emulating Hyper-V (cpuids).
> > >
> > > No, it's a Xen specific bug.  KVM in a hyper-v mode still emulates PCI
> > > so can still use KVM PV devices which are all PCI devices. So there's no
> problem
> > > there.
> >
> > Even Xen does not have a problem here; Xen would install its PV drivers in the
> guest.
> > So, the I/O infrastructure that would be installed in the guest would be based
> on the
> > host.
> > >
> > > Also, why override this in the guest? With time Xen hyper-v emulation
> > > might improve, meanwhile it's always possible to disable this in
> > > the hypervisor.
> > >
> > > > The specific case I ran into that required this patch was when I moved the
> > > VMBUS interrupts to be delivered via a special
> > > > hypervisor vector (to support full interrupt distribution amongst all VCPUs in
> > > the guest). This feature is not tagged in the CPUID
> > > > feature bits and without this check, I would install an interrupt handler for
> the
> > > hypervisor vector that clearly did not make
> > > > any sense in anything other than Hyper-V. I suspect there will be more such
> > > situations as we go forward.
> > > >
> > > > Regards,
> > > >
> > > > K. Y
> > >
> > > Why? Because there's no VMBUS on Xen? So check whether VMBUS exists?
> > On Linux, Hyper-V detection is used to load hyper-V related drivers (VMBUS
> etc.). For the case in
> > point, it was not clear to me how I could install the vmbus interrupt handler in a
> way that would
> > make sense when Xen was unconditionally emulating Hyper-V.
> >
> > Regards,
> >
> > K. Y
> 
> For example, check whether there is anything on the vmbus?
I think the right solution to this problem is to ensure that the guest does not have to do what you are proposing.
Based on the hypervisor detection, we load the drivers and setup the infrastructure to support these drivers.
There is no independent way of verifying if the host is Windows other than the hypervisor detection code.

If Xen were to change where it would not unconditionally emulate Hyper-V, I would not be opposed to taking
this check out.

K. Y
> 
> > >
> > > > >
> > > > > > >
> > > > > > > > ---
> > > > > > > >  arch/x86/kernel/cpu/mshyperv.c |    7 +++++++
> > > > > > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> > > > > > > b/arch/x86/kernel/cpu/mshyperv.c
> > > > > > > > index 646d192..4dab317 100644
> > > > > > > > --- a/arch/x86/kernel/cpu/mshyperv.c
> > > > > > > > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > > > > > > > @@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
> > > > > > > >  	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > > > > > > >  		return false;
> > > > > > > >
> > > > > > > > +	/*
> > > > > > > > +	 * Xen emulates Hyper-V to support enlightened Windows.
> > > > > > > > +	 * Check to see first if we are on a Xen Hypervisor.
> > > > > > > > +	 */
> > > > > > > > +	if (xen_cpuid_base())
> > > > > > > > +		return false;
> > > > > > > > +
> > > > > > > >  	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
> > > > > > > >  	      &eax, &hyp_signature[0], &hyp_signature[1],
> > > &hyp_signature[2]);
> > > > > > > >
> > > > > > > > --
> > > > > > > > 1.7.4.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/
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 

RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Jan Beulich]

>>> On 17.04.13 at 17:31, KY Srinivasan <kys@microsoft.com> wrote:
> If Xen were to change where it would not unconditionally emulate Hyper-V, I 
> would not be opposed to taking
> this check out.

But it doesn't do this unconditionally, only upon admin request.

Jan

RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[KY Srinivasan]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, April 17, 2013 11:51 AM
> To: KY Srinivasan; Michael S. Tsirkin
> Cc: olaf@aepfle.de; bp@alien8.de; apw@canonical.com; x86@kernel.org;
> tglx@linutronix.de; devel@linuxdriverproject.org; gregkh@linuxfoundation.org;
> jasowang@redhat.com; linux-kernel@vger.kernel.org; hpa@zytor.com
> Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> 
> >>> On 17.04.13 at 17:31, KY Srinivasan <kys@microsoft.com> wrote:
> > If Xen were to change where it would not unconditionally emulate Hyper-V, I
> > would not be opposed to taking
> > this check out.
> 
> But it doesn't do this unconditionally, only upon admin request.

>From the discussion we had a couple of months ago, the default setting was to enable
Hyper-V emulation for all guests. If this is not the case, we ought to be able to drop this.
However, I think it is not reasonable to add additional checks (in addition to hypervisor check)
to customize the run-time in the guest for the specific Hypervisor.

Regards,

K. Y
> 
> Jan
> 
> 

Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Michael S. Tsirkin]

On Wed, Apr 17, 2013 at 04:28:36PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Wednesday, April 17, 2013 11:51 AM
> > To: KY Srinivasan; Michael S. Tsirkin
> > Cc: olaf@aepfle.de; bp@alien8.de; apw@canonical.com; x86@kernel.org;
> > tglx@linutronix.de; devel@linuxdriverproject.org; gregkh@linuxfoundation.org;
> > jasowang@redhat.com; linux-kernel@vger.kernel.org; hpa@zytor.com
> > Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > 
> > >>> On 17.04.13 at 17:31, KY Srinivasan <kys@microsoft.com> wrote:
> > > If Xen were to change where it would not unconditionally emulate Hyper-V, I
> > > would not be opposed to taking
> > > this check out.
> > 
> > But it doesn't do this unconditionally, only upon admin request.
> 
> >From the discussion we had a couple of months ago, the default setting was to enable
> Hyper-V emulation for all guests. If this is not the case, we ought to be able to drop this.
> However, I think it is not reasonable to add additional checks (in addition to hypervisor check)
> to customize the run-time in the guest for the specific Hypervisor.
> 
> Regards,
> 
> K. Y

Parse error. What are you trying to say? I'm just saying it's best to do
things in the way that make it possible for Xen to implement hyperv in a
more complete way in the future and have things just work
and in a way that does not change guest/hypervisor interface.

> > 
> > Jan
> > 
> > 
> 

RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[KY Srinivasan]

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Thursday, April 18, 2013 3:48 AM
> To: KY Srinivasan
> Cc: Jan Beulich; olaf@aepfle.de; bp@alien8.de; apw@canonical.com;
> x86@kernel.org; tglx@linutronix.de; devel@linuxdriverproject.org;
> gregkh@linuxfoundation.org; jasowang@redhat.com; linux-
> kernel@vger.kernel.org; hpa@zytor.com
> Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> 
> On Wed, Apr 17, 2013 at 04:28:36PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Jan Beulich [mailto:JBeulich@suse.com]
> > > Sent: Wednesday, April 17, 2013 11:51 AM
> > > To: KY Srinivasan; Michael S. Tsirkin
> > > Cc: olaf@aepfle.de; bp@alien8.de; apw@canonical.com; x86@kernel.org;
> > > tglx@linutronix.de; devel@linuxdriverproject.org;
> gregkh@linuxfoundation.org;
> > > jasowang@redhat.com; linux-kernel@vger.kernel.org; hpa@zytor.com
> > > Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > >
> > > >>> On 17.04.13 at 17:31, KY Srinivasan <kys@microsoft.com> wrote:
> > > > If Xen were to change where it would not unconditionally emulate Hyper-V,
> I
> > > > would not be opposed to taking
> > > > this check out.
> > >
> > > But it doesn't do this unconditionally, only upon admin request.
> >
> > >From the discussion we had a couple of months ago, the default setting was to
> enable
> > Hyper-V emulation for all guests. If this is not the case, we ought to be able to
> drop this.
> > However, I think it is not reasonable to add additional checks (in addition to
> hypervisor check)
> > to customize the run-time in the guest for the specific Hypervisor.
> >
> > Regards,
> >
> > K. Y
> 
> Parse error. What are you trying to say? I'm just saying it's best to do
> things in the way that make it possible for Xen to implement hyperv in a
> more complete way in the future and have things just work
> and in a way that does not change guest/hypervisor interface.

There is no error to parse here. I need to setup the vmbus interrupt before I
can contact the host. As I said I am fine with dropping this check if Xen behavior is
changed appropriately. We have a mechanism for hypervisor detection and a 
mechanism for discovering features within a hypervisor. Once we confirm the
existence of a specific hypervisor, we ought to be able to do what is needed for
that hypervisor (unless the hypervisor feature flag precludes it) without having to
go through hoops to discover if we are in a hypervisor emulation mode where the emulation
may not be complete. In this particular case, the need for VMBUS related infrastructure cannot be
currently determined via the feature detection mechanism. 

For features that cannot be detected via CPUID feature bits, we can use some other CPUID based
mechanism to discriminate. For instance in the case under discussion, I could  install
hyperv_callback_vector only if we are on an environment that supports the vmbus infrastructure.
Unfortunately there is no positive test for this. The best we can do is a negative test. I could move the 
Xen check and conditionally install the hyperv_callback vector. 

Regards,

K. Y
 
 
> 
> > >
> > > Jan
> > >
> > >
> >
> 

RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[KY Srinivasan]

> -----Original Message-----
> From: devel [mailto:devel-bounces@linuxdriverproject.org] On Behalf Of KY
> Srinivasan
> Sent: Thursday, April 18, 2013 9:23 AM
> To: Michael S. Tsirkin
> Cc: olaf@aepfle.de; gregkh@linuxfoundation.org; jasowang@redhat.com;
> x86@kernel.org; linux-kernel@vger.kernel.org; bp@alien8.de; Jan Beulich;
> hpa@zytor.com; apw@canonical.com; devel@linuxdriverproject.org;
> tglx@linutronix.de
> Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> 
> 
> 
> > -----Original Message-----
> > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > Sent: Thursday, April 18, 2013 3:48 AM
> > To: KY Srinivasan
> > Cc: Jan Beulich; olaf@aepfle.de; bp@alien8.de; apw@canonical.com;
> > x86@kernel.org; tglx@linutronix.de; devel@linuxdriverproject.org;
> > gregkh@linuxfoundation.org; jasowang@redhat.com; linux-
> > kernel@vger.kernel.org; hpa@zytor.com
> > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> >
> > On Wed, Apr 17, 2013 at 04:28:36PM +0000, KY Srinivasan wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jan Beulich [mailto:JBeulich@suse.com]
> > > > Sent: Wednesday, April 17, 2013 11:51 AM
> > > > To: KY Srinivasan; Michael S. Tsirkin
> > > > Cc: olaf@aepfle.de; bp@alien8.de; apw@canonical.com; x86@kernel.org;
> > > > tglx@linutronix.de; devel@linuxdriverproject.org;
> > gregkh@linuxfoundation.org;
> > > > jasowang@redhat.com; linux-kernel@vger.kernel.org; hpa@zytor.com
> > > > Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-
> V
> > > >
> > > > >>> On 17.04.13 at 17:31, KY Srinivasan <kys@microsoft.com> wrote:
> > > > > If Xen were to change where it would not unconditionally emulate Hyper-
> V,
> > I
> > > > > would not be opposed to taking
> > > > > this check out.
> > > >
> > > > But it doesn't do this unconditionally, only upon admin request.
> > >
> > > >From the discussion we had a couple of months ago, the default setting was
> to
> > enable
> > > Hyper-V emulation for all guests. If this is not the case, we ought to be able to
> > drop this.
> > > However, I think it is not reasonable to add additional checks (in addition to
> > hypervisor check)
> > > to customize the run-time in the guest for the specific Hypervisor.
> > >
> > > Regards,
> > >
> > > K. Y
> >
> > Parse error. What are you trying to say? I'm just saying it's best to do
> > things in the way that make it possible for Xen to implement hyperv in a
> > more complete way in the future and have things just work
> > and in a way that does not change guest/hypervisor interface.
> 
> There is no error to parse here. I need to setup the vmbus interrupt before I
> can contact the host. As I said I am fine with dropping this check if Xen behavior is
> changed appropriately. We have a mechanism for hypervisor detection and a
> mechanism for discovering features within a hypervisor. Once we confirm the
> existence of a specific hypervisor, we ought to be able to do what is needed for
> that hypervisor (unless the hypervisor feature flag precludes it) without having to
> go through hoops to discover if we are in a hypervisor emulation mode where
> the emulation
> may not be complete. In this particular case, the need for VMBUS related
> infrastructure cannot be
> currently determined via the feature detection mechanism.
> 
> For features that cannot be detected via CPUID feature bits, we can use some
> other CPUID based
> mechanism to discriminate. For instance in the case under discussion, I could
> install
> hyperv_callback_vector only if we are on an environment that supports the
> vmbus infrastructure.
> Unfortunately there is no positive test for this. The best we can do is a negative
> test. I could move the
> Xen check and conditionally install the hyperv_callback vector.

Michael,

I think I can address the problem you have raised. I will send a patch out soon.

Regards,

K. Y
> 
> Regards,
> 
> K. Y
> 
> 
> >
> > > >
> > > > Jan
> > > >
> > > >
> > >
> >
> 
> 
> _______________________________________________
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
> 

RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Jan Beulich]

>>> On 17.04.13 at 15:20, KY Srinivasan <kys@microsoft.com> wrote:
> If I recall correctly, the issue here was that Xen was enabling Hyper-V 
> emulation un-conditionally even for Linux guests.

To make this a little more precise - Xen is doing so only when the
guest config tells it to.

Jan

Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Michael S. Tsirkin]

On Wed, Apr 17, 2013 at 02:52:42PM +0100, Jan Beulich wrote:
> >>> On 17.04.13 at 15:20, KY Srinivasan <kys@microsoft.com> wrote:
> > If I recall correctly, the issue here was that Xen was enabling Hyper-V 
> > emulation un-conditionally even for Linux guests.
> 
> To make this a little more precise - Xen is doing so only when the
> guest config tells it to.
> 
> Jan

So it's something explicitly requested for this guest?  Then I don't
understand why does not make sense to override it in guest.

Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Michael S. Tsirkin]

On Wed, Apr 17, 2013 at 04:01:02PM +0300, Michael S. Tsirkin wrote:
> On Wed, Apr 17, 2013 at 02:52:42PM +0100, Jan Beulich wrote:
> > >>> On 17.04.13 at 15:20, KY Srinivasan <kys@microsoft.com> wrote:
> > > If I recall correctly, the issue here was that Xen was enabling Hyper-V 
> > > emulation un-conditionally even for Linux guests.
> > 
> > To make this a little more precise - Xen is doing so only when the
> > guest config tells it to.
> > 
> > Jan
> 
> So it's something explicitly requested for this guest?  Then I don't
> understand why does not make sense to override it in guest.

Typo, should have been "why does *it* make sense to override it in
guest.

Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Jan Beulich]

>>> On 17.04.13 at 15:01, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Apr 17, 2013 at 02:52:42PM +0100, Jan Beulich wrote:
>> >>> On 17.04.13 at 15:20, KY Srinivasan <kys@microsoft.com> wrote:
>> > If I recall correctly, the issue here was that Xen was enabling Hyper-V 
>> > emulation un-conditionally even for Linux guests.
>> 
>> To make this a little more precise - Xen is doing so only when the
>> guest config tells it to.
> 
> So it's something explicitly requested for this guest?  Then I don't
> understand why does not make sense to override it in guest.

Iirc it was/is XenServer which enable Hyper-V emulation for all HVM
guests, which clearly is the wrong thing. I was personally also not
really in agreement with the override in the kernel, but it was
decided to do it that way at that point in time. As a consequence,
I don't object this to be reverted.

Jan

Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[H. Peter Anvin]

On 04/17/2013 07:09 AM, Jan Beulich wrote:
> 
> Iirc it was/is XenServer which enable Hyper-V emulation for all HVM
> guests, which clearly is the wrong thing. I was personally also not
> really in agreement with the override in the kernel, but it was
> decided to do it that way at that point in time. As a consequence,
> I don't object this to be reverted.
> 

I was not exactly happy with the idea either.  I'm sorry if I mixed up
Xen and KVM.

Furthermore, as I recall, it only affected kernels where Xen was
compiled out, or something like that.

It would definitely be best to fix the HyperV driver to be more
robust... that may be important across HyperV releases, too.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

[PATCH 3/3] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[K. Y. Srinivasan]

Starting with win8, vmbus interrupts can be delivered on any VCPU in the guest
and furthermore can be concurrently active on multiple VCPUs. Support this
interrupt delivery model by setting up a separate IDT entry for Hyper-V vmbus.
interrupts. I would like to thank Jan Beulich <JBeulich@suse.com> and
Thomas Gleixner <tglx@linutronix.de>, for their help.

In this version of the patch, based on the feedback, I have merged the IDT
vector for Xen and Hyper-V and made the necessary adjustments. Furhermore,
based on Jan's feedback I have added the necessary compilation switches.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 arch/x86/include/asm/irq_vectors.h |    4 +-
 arch/x86/include/asm/mshyperv.h    |    4 +++
 arch/x86/kernel/cpu/mshyperv.c     |   44 ++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/entry_32.S         |    9 ++++++-
 arch/x86/kernel/entry_64.S         |    7 +++++-
 drivers/xen/events.c               |    7 +++--
 6 files changed, 68 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
index 1508e51..aac5fa6 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -109,8 +109,8 @@
 
 #define UV_BAU_MESSAGE			0xf5
 
-/* Xen vector callback to receive events in a HVM domain */
-#define XEN_HVM_EVTCHN_CALLBACK		0xf3
+/* Vector on which hypervisor callbacks will be delivered */
+#define HYPERVISOR_CALLBACK_VECTOR	0xf3
 
 /*
  * Local APIC timer IRQ vector is on a different priority level,
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 79ce568..c2934be 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -11,4 +11,8 @@ struct ms_hyperv_info {
 
 extern struct ms_hyperv_info ms_hyperv;
 
+void hyperv_callback_vector(void);
+void hyperv_vector_handler(struct pt_regs *regs);
+void hv_register_vmbus_handler(int irq, irq_handler_t handler);
+
 #endif
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 4dab317..a7d26d8 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -14,10 +14,15 @@
 #include <linux/time.h>
 #include <linux/clocksource.h>
 #include <linux/module.h>
+#include <linux/hardirq.h>
+#include <linux/interrupt.h>
 #include <asm/processor.h>
 #include <asm/hypervisor.h>
 #include <asm/hyperv.h>
 #include <asm/mshyperv.h>
+#include <asm/desc.h>
+#include <asm/idle.h>
+#include <asm/irq_regs.h>
 
 struct ms_hyperv_info ms_hyperv;
 EXPORT_SYMBOL_GPL(ms_hyperv);
@@ -77,6 +82,12 @@ static void __init ms_hyperv_init_platform(void)
 
 	if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
 		clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
+#if IS_ENABLED(CONFIG_HYPERV)
+	/*
+	 * Setup the IDT for hypervisor callback.
+	 */
+	alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, hyperv_callback_vector);
+#endif
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
@@ -85,3 +96,36 @@ const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
 	.init_platform		= ms_hyperv_init_platform,
 };
 EXPORT_SYMBOL(x86_hyper_ms_hyperv);
+
+#if IS_ENABLED(CONFIG_HYPERV)
+static int vmbus_irq = -1;
+static irq_handler_t vmbus_isr;
+
+void hv_register_vmbus_handler(int irq, irq_handler_t handler)
+{
+	vmbus_irq = irq;
+	vmbus_isr = handler;
+}
+
+void hyperv_vector_handler(struct pt_regs *regs)
+{
+	struct pt_regs *old_regs = set_irq_regs(regs);
+	struct irq_desc *desc;
+
+	irq_enter();
+	exit_idle();
+
+	desc = irq_to_desc(vmbus_irq);
+
+	if (desc)
+		generic_handle_irq_desc(vmbus_irq, desc);
+
+	irq_exit();
+	set_irq_regs(old_regs);
+}
+#else
+void hv_register_vmbus_handler(int irq, irq_handler_t handler)
+{
+}
+#endif
+EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 352e5a9..8f3e2de 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1046,11 +1046,18 @@ ENTRY(xen_failsafe_callback)
 	_ASM_EXTABLE(4b,9b)
 ENDPROC(xen_failsafe_callback)
 
-BUILD_INTERRUPT3(xen_hvm_callback_vector, XEN_HVM_EVTCHN_CALLBACK,
+BUILD_INTERRUPT3(xen_hvm_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
 		xen_evtchn_do_upcall)
 
 #endif	/* CONFIG_XEN */
 
+#if IS_ENABLED(CONFIG_HYPERV)
+
+BUILD_INTERRUPT3(hyperv_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
+	hyperv_vector_handler)
+
+#endif /* CONFIG_HYPERV */
+
 #ifdef CONFIG_FUNCTION_TRACER
 #ifdef CONFIG_DYNAMIC_FTRACE
 
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index d5113c3..c1d01e6 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1446,11 +1446,16 @@ ENTRY(xen_failsafe_callback)
 	CFI_ENDPROC
 END(xen_failsafe_callback)
 
-apicinterrupt XEN_HVM_EVTCHN_CALLBACK \
+apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
 	xen_hvm_callback_vector xen_evtchn_do_upcall
 
 #endif /* CONFIG_XEN */
 
+#if IS_ENABLED(CONFIG_HYPERV)
+apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
+	hyperv_callback_vector hyperv_vector_handler
+#endif /* CONFIG_HYPERV */
+
 /*
  * Some functions should be protected against kprobes
  */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4293c57..a54401e 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1787,7 +1787,7 @@ void xen_callback_vector(void)
 	int rc;
 	uint64_t callback_via;
 	if (xen_have_vector_callback) {
-		callback_via = HVM_CALLBACK_VECTOR(XEN_HVM_EVTCHN_CALLBACK);
+		callback_via = HVM_CALLBACK_VECTOR(HYPERVISOR_CALLBACK_VECTOR);
 		rc = xen_set_callback_via(callback_via);
 		if (rc) {
 			printk(KERN_ERR "Request for Xen HVM callback vector"
@@ -1798,8 +1798,9 @@ void xen_callback_vector(void)
 		printk(KERN_INFO "Xen HVM callback vector for event delivery is "
 				"enabled\n");
 		/* in the restore case the vector has already been allocated */
-		if (!test_bit(XEN_HVM_EVTCHN_CALLBACK, used_vectors))
-			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
+		if (!test_bit(HYPERVISOR_CALLBACK_VECTOR, used_vectors))
+			alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
+					xen_hvm_callback_vector);
 	}
 }
 #else
-- 
1.7.4.1

[tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[tip-bot for K. Y. Srinivasan]

Commit-ID:  bc2b0331e077f576369a2b6c75d15ed4de4ef91f
Gitweb:     http://git.kernel.org/tip/bc2b0331e077f576369a2b6c75d15ed4de4ef91f
Author:     K. Y. Srinivasan <kys@microsoft.com>
AuthorDate: Sun, 3 Feb 2013 17:22:39 -0800
Committer:  H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Tue, 12 Feb 2013 16:27:15 -0800

X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

Starting with win8, vmbus interrupts can be delivered on any VCPU in the guest
and furthermore can be concurrently active on multiple VCPUs. Support this
interrupt delivery model by setting up a separate IDT entry for Hyper-V vmbus.
interrupts. I would like to thank Jan Beulich <JBeulich@suse.com> and
Thomas Gleixner <tglx@linutronix.de>, for their help.

In this version of the patch, based on the feedback, I have merged the IDT
vector for Xen and Hyper-V and made the necessary adjustments. Furhermore,
based on Jan's feedback I have added the necessary compilation switches.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Link: http://lkml.kernel.org/r/1359940959-32168-3-git-send-email-kys@microsoft.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
 arch/x86/include/asm/irq_vectors.h |  4 ++--
 arch/x86/include/asm/mshyperv.h    |  4 ++++
 arch/x86/kernel/cpu/mshyperv.c     | 44 ++++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/entry_32.S         |  9 +++++++-
 arch/x86/kernel/entry_64.S         |  7 +++++-
 drivers/xen/events.c               |  7 +++---
 6 files changed, 68 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
index 1508e51..aac5fa6 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -109,8 +109,8 @@
 
 #define UV_BAU_MESSAGE			0xf5
 
-/* Xen vector callback to receive events in a HVM domain */
-#define XEN_HVM_EVTCHN_CALLBACK		0xf3
+/* Vector on which hypervisor callbacks will be delivered */
+#define HYPERVISOR_CALLBACK_VECTOR	0xf3
 
 /*
  * Local APIC timer IRQ vector is on a different priority level,
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 79ce568..c2934be 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -11,4 +11,8 @@ struct ms_hyperv_info {
 
 extern struct ms_hyperv_info ms_hyperv;
 
+void hyperv_callback_vector(void);
+void hyperv_vector_handler(struct pt_regs *regs);
+void hv_register_vmbus_handler(int irq, irq_handler_t handler);
+
 #endif
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 4dab317..a7d26d8 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -14,10 +14,15 @@
 #include <linux/time.h>
 #include <linux/clocksource.h>
 #include <linux/module.h>
+#include <linux/hardirq.h>
+#include <linux/interrupt.h>
 #include <asm/processor.h>
 #include <asm/hypervisor.h>
 #include <asm/hyperv.h>
 #include <asm/mshyperv.h>
+#include <asm/desc.h>
+#include <asm/idle.h>
+#include <asm/irq_regs.h>
 
 struct ms_hyperv_info ms_hyperv;
 EXPORT_SYMBOL_GPL(ms_hyperv);
@@ -77,6 +82,12 @@ static void __init ms_hyperv_init_platform(void)
 
 	if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
 		clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
+#if IS_ENABLED(CONFIG_HYPERV)
+	/*
+	 * Setup the IDT for hypervisor callback.
+	 */
+	alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, hyperv_callback_vector);
+#endif
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
@@ -85,3 +96,36 @@ const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
 	.init_platform		= ms_hyperv_init_platform,
 };
 EXPORT_SYMBOL(x86_hyper_ms_hyperv);
+
+#if IS_ENABLED(CONFIG_HYPERV)
+static int vmbus_irq = -1;
+static irq_handler_t vmbus_isr;
+
+void hv_register_vmbus_handler(int irq, irq_handler_t handler)
+{
+	vmbus_irq = irq;
+	vmbus_isr = handler;
+}
+
+void hyperv_vector_handler(struct pt_regs *regs)
+{
+	struct pt_regs *old_regs = set_irq_regs(regs);
+	struct irq_desc *desc;
+
+	irq_enter();
+	exit_idle();
+
+	desc = irq_to_desc(vmbus_irq);
+
+	if (desc)
+		generic_handle_irq_desc(vmbus_irq, desc);
+
+	irq_exit();
+	set_irq_regs(old_regs);
+}
+#else
+void hv_register_vmbus_handler(int irq, irq_handler_t handler)
+{
+}
+#endif
+EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 6ed91d9..8831176 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1091,11 +1091,18 @@ ENTRY(xen_failsafe_callback)
 	_ASM_EXTABLE(4b,9b)
 ENDPROC(xen_failsafe_callback)
 
-BUILD_INTERRUPT3(xen_hvm_callback_vector, XEN_HVM_EVTCHN_CALLBACK,
+BUILD_INTERRUPT3(xen_hvm_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
 		xen_evtchn_do_upcall)
 
 #endif	/* CONFIG_XEN */
 
+#if IS_ENABLED(CONFIG_HYPERV)
+
+BUILD_INTERRUPT3(hyperv_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
+	hyperv_vector_handler)
+
+#endif /* CONFIG_HYPERV */
+
 #ifdef CONFIG_FUNCTION_TRACER
 #ifdef CONFIG_DYNAMIC_FTRACE
 
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index cb3c591..048f224 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1454,11 +1454,16 @@ ENTRY(xen_failsafe_callback)
 	CFI_ENDPROC
 END(xen_failsafe_callback)
 
-apicinterrupt XEN_HVM_EVTCHN_CALLBACK \
+apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
 	xen_hvm_callback_vector xen_evtchn_do_upcall
 
 #endif /* CONFIG_XEN */
 
+#if IS_ENABLED(CONFIG_HYPERV)
+apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
+	hyperv_callback_vector hyperv_vector_handler
+#endif /* CONFIG_HYPERV */
+
 /*
  * Some functions should be protected against kprobes
  */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 74d77df..22f77c5 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1787,7 +1787,7 @@ void xen_callback_vector(void)
 	int rc;
 	uint64_t callback_via;
 	if (xen_have_vector_callback) {
-		callback_via = HVM_CALLBACK_VECTOR(XEN_HVM_EVTCHN_CALLBACK);
+		callback_via = HVM_CALLBACK_VECTOR(HYPERVISOR_CALLBACK_VECTOR);
 		rc = xen_set_callback_via(callback_via);
 		if (rc) {
 			printk(KERN_ERR "Request for Xen HVM callback vector"
@@ -1798,8 +1798,9 @@ void xen_callback_vector(void)
 		printk(KERN_INFO "Xen HVM callback vector for event delivery is "
 				"enabled\n");
 		/* in the restore case the vector has already been allocated */
-		if (!test_bit(XEN_HVM_EVTCHN_CALLBACK, used_vectors))
-			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
+		if (!test_bit(HYPERVISOR_CALLBACK_VECTOR, used_vectors))
+			alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
+					xen_hvm_callback_vector);
 	}
 }
 #else

[tip:x86/hyperv] x86, hyperv: HYPERV depends on X86_LOCAL_APIC

[tip-bot for H. Peter Anvin]

Commit-ID:  cb20e5f2c8d6ba7440a32f4d70c0755bceb36e78
Gitweb:     http://git.kernel.org/tip/cb20e5f2c8d6ba7440a32f4d70c0755bceb36e78
Author:     H. Peter Anvin <hpa@linux.intel.com>
AuthorDate: Tue, 12 Feb 2013 17:46:23 -0800
Committer:  H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Tue, 12 Feb 2013 17:46:23 -0800

x86, hyperv: HYPERV depends on X86_LOCAL_APIC

In order to compile in the special Hyper-V interrupt vector, we need
infrastructure in arch/x86/apic/apic.c.  At least for now, simply
require CONFIG_X86_LOCAL_APIC in order to enable CONFIG_HYPERV.

Link: http://lkml.kernel.org/r/tip-bc2b0331e077f576369a2b6c75d15ed4de4ef91f@git.kernel.org
Cc: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
 drivers/hv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index b38ef6d..64630f1 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -2,7 +2,7 @@ menu "Microsoft Hyper-V guest support"
 
 config HYPERV
 	tristate "Microsoft Hyper-V client drivers"
-	depends on X86 && ACPI && PCI
+	depends on X86 && ACPI && PCI && X86_LOCAL_APIC
 	help
 	  Select this option to run Linux as a Hyper-V client operating
 	  system.

RE: [tip:x86/hyperv] x86, hyperv: HYPERV depends on X86_LOCAL_APIC

[KY Srinivasan]

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



> -----Original Message-----
> From: tip tree robot [mailto:tipbot@zytor.com] On Behalf Of tip-bot for H. Peter
> Anvin
> Sent: Tuesday, February 12, 2013 8:59 PM
> To: linux-tip-commits@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; hpa@zytor.com; mingo@kernel.org; KY
> Srinivasan; tglx@linutronix.de; hpa@linux.intel.com
> Subject: [tip:x86/hyperv] x86, hyperv: HYPERV depends on X86_LOCAL_APIC
> 
> Commit-ID:  cb20e5f2c8d6ba7440a32f4d70c0755bceb36e78
> Gitweb:
> http://git.kernel.org/tip/cb20e5f2c8d6ba7440a32f4d70c0755bceb36e78
> Author:     H. Peter Anvin <hpa@linux.intel.com>
> AuthorDate: Tue, 12 Feb 2013 17:46:23 -0800
> Committer:  H. Peter Anvin <hpa@linux.intel.com>
> CommitDate: Tue, 12 Feb 2013 17:46:23 -0800
> 
> x86, hyperv: HYPERV depends on X86_LOCAL_APIC
> 
> In order to compile in the special Hyper-V interrupt vector, we need
> infrastructure in arch/x86/apic/apic.c.  At least for now, simply
> require CONFIG_X86_LOCAL_APIC in order to enable CONFIG_HYPERV.
> 
> Link: http://lkml.kernel.org/r/tip-
> bc2b0331e077f576369a2b6c75d15ed4de4ef91f@git.kernel.org
> Cc: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
> ---
>  drivers/hv/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index b38ef6d..64630f1 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -2,7 +2,7 @@ menu "Microsoft Hyper-V guest support"
> 
>  config HYPERV
>  	tristate "Microsoft Hyper-V client drivers"
> -	depends on X86 && ACPI && PCI
> +	depends on X86 && ACPI && PCI && X86_LOCAL_APIC
>  	help
>  	  Select this option to run Linux as a Hyper-V client operating
>  	  system.
> 
Thank you.

K. Y
ÿôèº{.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: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Yinghai Lu]

On Tue, Feb 12, 2013 at 4:58 PM, tip-bot for K. Y. Srinivasan
<kys@microsoft.com> wrote:
> Commit-ID:  bc2b0331e077f576369a2b6c75d15ed4de4ef91f
> Gitweb:     http://git.kernel.org/tip/bc2b0331e077f576369a2b6c75d15ed4de4ef91f
> Author:     K. Y. Srinivasan <kys@microsoft.com>
> AuthorDate: Sun, 3 Feb 2013 17:22:39 -0800
> Committer:  H. Peter Anvin <hpa@linux.intel.com>
> CommitDate: Tue, 12 Feb 2013 16:27:15 -0800
>
> X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
>
> Starting with win8, vmbus interrupts can be delivered on any VCPU in the guest
> and furthermore can be concurrently active on multiple VCPUs. Support this
> interrupt delivery model by setting up a separate IDT entry for Hyper-V vmbus.
> interrupts. I would like to thank Jan Beulich <JBeulich@suse.com> and
> Thomas Gleixner <tglx@linutronix.de>, for their help.
>
> In this version of the patch, based on the feedback, I have merged the IDT
> vector for Xen and Hyper-V and made the necessary adjustments. Furhermore,
> based on Jan's feedback I have added the necessary compilation switches.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Link: http://lkml.kernel.org/r/1359940959-32168-3-git-send-email-kys@microsoft.com
> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
> ---
>  arch/x86/include/asm/irq_vectors.h |  4 ++--
>  arch/x86/include/asm/mshyperv.h    |  4 ++++
>  arch/x86/kernel/cpu/mshyperv.c     | 44 ++++++++++++++++++++++++++++++++++++++
>  arch/x86/kernel/entry_32.S         |  9 +++++++-
>  arch/x86/kernel/entry_64.S         |  7 +++++-
>  drivers/xen/events.c               |  7 +++---
>  6 files changed, 68 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
> index 1508e51..aac5fa6 100644
> --- a/arch/x86/include/asm/irq_vectors.h
> +++ b/arch/x86/include/asm/irq_vectors.h
> @@ -109,8 +109,8 @@
>
>  #define UV_BAU_MESSAGE                 0xf5
>
> -/* Xen vector callback to receive events in a HVM domain */
> -#define XEN_HVM_EVTCHN_CALLBACK                0xf3
> +/* Vector on which hypervisor callbacks will be delivered */
> +#define HYPERVISOR_CALLBACK_VECTOR     0xf3
>
>  /*
>   * Local APIC timer IRQ vector is on a different priority level,
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index 79ce568..c2934be 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -11,4 +11,8 @@ struct ms_hyperv_info {
>
>  extern struct ms_hyperv_info ms_hyperv;
>
> +void hyperv_callback_vector(void);
> +void hyperv_vector_handler(struct pt_regs *regs);
> +void hv_register_vmbus_handler(int irq, irq_handler_t handler);
> +
>  #endif
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index 4dab317..a7d26d8 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -14,10 +14,15 @@
>  #include <linux/time.h>
>  #include <linux/clocksource.h>
>  #include <linux/module.h>
> +#include <linux/hardirq.h>
> +#include <linux/interrupt.h>
>  #include <asm/processor.h>
>  #include <asm/hypervisor.h>
>  #include <asm/hyperv.h>
>  #include <asm/mshyperv.h>
> +#include <asm/desc.h>
> +#include <asm/idle.h>
> +#include <asm/irq_regs.h>
>
>  struct ms_hyperv_info ms_hyperv;
>  EXPORT_SYMBOL_GPL(ms_hyperv);
> @@ -77,6 +82,12 @@ static void __init ms_hyperv_init_platform(void)
>
>         if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
>                 clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
> +#if IS_ENABLED(CONFIG_HYPERV)
> +       /*
> +        * Setup the IDT for hypervisor callback.
> +        */
> +       alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, hyperv_callback_vector);
> +#endif
>  }
>
>  const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
> @@ -85,3 +96,36 @@ const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
>         .init_platform          = ms_hyperv_init_platform,
>  };
>  EXPORT_SYMBOL(x86_hyper_ms_hyperv);
> +
> +#if IS_ENABLED(CONFIG_HYPERV)
> +static int vmbus_irq = -1;
> +static irq_handler_t vmbus_isr;
> +
> +void hv_register_vmbus_handler(int irq, irq_handler_t handler)
> +{
> +       vmbus_irq = irq;
> +       vmbus_isr = handler;
> +}
> +
> +void hyperv_vector_handler(struct pt_regs *regs)
> +{
> +       struct pt_regs *old_regs = set_irq_regs(regs);
> +       struct irq_desc *desc;
> +
> +       irq_enter();
> +       exit_idle();
> +
> +       desc = irq_to_desc(vmbus_irq);
> +
> +       if (desc)
> +               generic_handle_irq_desc(vmbus_irq, desc);
> +
> +       irq_exit();
> +       set_irq_regs(old_regs);
> +}
> +#else
> +void hv_register_vmbus_handler(int irq, irq_handler_t handler)
> +{
> +}
> +#endif
> +EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 6ed91d9..8831176 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -1091,11 +1091,18 @@ ENTRY(xen_failsafe_callback)
>         _ASM_EXTABLE(4b,9b)
>  ENDPROC(xen_failsafe_callback)
>
> -BUILD_INTERRUPT3(xen_hvm_callback_vector, XEN_HVM_EVTCHN_CALLBACK,
> +BUILD_INTERRUPT3(xen_hvm_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
>                 xen_evtchn_do_upcall)
>
>  #endif /* CONFIG_XEN */
>
> +#if IS_ENABLED(CONFIG_HYPERV)
> +
> +BUILD_INTERRUPT3(hyperv_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
> +       hyperv_vector_handler)
> +
> +#endif /* CONFIG_HYPERV */
> +
>  #ifdef CONFIG_FUNCTION_TRACER
>  #ifdef CONFIG_DYNAMIC_FTRACE
>
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index cb3c591..048f224 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -1454,11 +1454,16 @@ ENTRY(xen_failsafe_callback)
>         CFI_ENDPROC
>  END(xen_failsafe_callback)
>
> -apicinterrupt XEN_HVM_EVTCHN_CALLBACK \
> +apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
>         xen_hvm_callback_vector xen_evtchn_do_upcall
>
>  #endif /* CONFIG_XEN */
>
> +#if IS_ENABLED(CONFIG_HYPERV)
> +apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
> +       hyperv_callback_vector hyperv_vector_handler
> +#endif /* CONFIG_HYPERV */
> +

so #ifdef CONFIG_HYPERV does not work here?

Yinghai

RE: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[KY Srinivasan]

> -----Original Message-----
> From: yhlu.kernel@gmail.com [mailto:yhlu.kernel@gmail.com] On Behalf Of
> Yinghai Lu
> Sent: Tuesday, February 12, 2013 9:56 PM
> To: mingo@kernel.org; hpa@zytor.com; linux-kernel@vger.kernel.org; KY
> Srinivasan; tglx@linutronix.de; hpa@linux.intel.com
> Cc: linux-tip-commits@vger.kernel.org
> Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special
> hypervisor interrupts
> 
> On Tue, Feb 12, 2013 at 4:58 PM, tip-bot for K. Y. Srinivasan
> <kys@microsoft.com> wrote:
> > Commit-ID:  bc2b0331e077f576369a2b6c75d15ed4de4ef91f
> > Gitweb:
> http://git.kernel.org/tip/bc2b0331e077f576369a2b6c75d15ed4de4ef91f
> > Author:     K. Y. Srinivasan <kys@microsoft.com>
> > AuthorDate: Sun, 3 Feb 2013 17:22:39 -0800
> > Committer:  H. Peter Anvin <hpa@linux.intel.com>
> > CommitDate: Tue, 12 Feb 2013 16:27:15 -0800
> >
> > X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
> >
> > Starting with win8, vmbus interrupts can be delivered on any VCPU in the guest
> > and furthermore can be concurrently active on multiple VCPUs. Support this
> > interrupt delivery model by setting up a separate IDT entry for Hyper-V vmbus.
> > interrupts. I would like to thank Jan Beulich <JBeulich@suse.com> and
> > Thomas Gleixner <tglx@linutronix.de>, for their help.
> >
> > In this version of the patch, based on the feedback, I have merged the IDT
> > vector for Xen and Hyper-V and made the necessary adjustments. Furhermore,
> > based on Jan's feedback I have added the necessary compilation switches.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Link: http://lkml.kernel.org/r/1359940959-32168-3-git-send-email-
> kys@microsoft.com
> > Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
> > ---
> >  arch/x86/include/asm/irq_vectors.h |  4 ++--
> >  arch/x86/include/asm/mshyperv.h    |  4 ++++
> >  arch/x86/kernel/cpu/mshyperv.c     | 44
> ++++++++++++++++++++++++++++++++++++++
> >  arch/x86/kernel/entry_32.S         |  9 +++++++-
> >  arch/x86/kernel/entry_64.S         |  7 +++++-
> >  drivers/xen/events.c               |  7 +++---
> >  6 files changed, 68 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/irq_vectors.h
> b/arch/x86/include/asm/irq_vectors.h
> > index 1508e51..aac5fa6 100644
> > --- a/arch/x86/include/asm/irq_vectors.h
> > +++ b/arch/x86/include/asm/irq_vectors.h
> > @@ -109,8 +109,8 @@
> >
> >  #define UV_BAU_MESSAGE                 0xf5
> >
> > -/* Xen vector callback to receive events in a HVM domain */
> > -#define XEN_HVM_EVTCHN_CALLBACK                0xf3
> > +/* Vector on which hypervisor callbacks will be delivered */
> > +#define HYPERVISOR_CALLBACK_VECTOR     0xf3
> >
> >  /*
> >   * Local APIC timer IRQ vector is on a different priority level,
> > diff --git a/arch/x86/include/asm/mshyperv.h
> b/arch/x86/include/asm/mshyperv.h
> > index 79ce568..c2934be 100644
> > --- a/arch/x86/include/asm/mshyperv.h
> > +++ b/arch/x86/include/asm/mshyperv.h
> > @@ -11,4 +11,8 @@ struct ms_hyperv_info {
> >
> >  extern struct ms_hyperv_info ms_hyperv;
> >
> > +void hyperv_callback_vector(void);
> > +void hyperv_vector_handler(struct pt_regs *regs);
> > +void hv_register_vmbus_handler(int irq, irq_handler_t handler);
> > +
> >  #endif
> > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> b/arch/x86/kernel/cpu/mshyperv.c
> > index 4dab317..a7d26d8 100644
> > --- a/arch/x86/kernel/cpu/mshyperv.c
> > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > @@ -14,10 +14,15 @@
> >  #include <linux/time.h>
> >  #include <linux/clocksource.h>
> >  #include <linux/module.h>
> > +#include <linux/hardirq.h>
> > +#include <linux/interrupt.h>
> >  #include <asm/processor.h>
> >  #include <asm/hypervisor.h>
> >  #include <asm/hyperv.h>
> >  #include <asm/mshyperv.h>
> > +#include <asm/desc.h>
> > +#include <asm/idle.h>
> > +#include <asm/irq_regs.h>
> >
> >  struct ms_hyperv_info ms_hyperv;
> >  EXPORT_SYMBOL_GPL(ms_hyperv);
> > @@ -77,6 +82,12 @@ static void __init ms_hyperv_init_platform(void)
> >
> >         if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
> >                 clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
> > +#if IS_ENABLED(CONFIG_HYPERV)
> > +       /*
> > +        * Setup the IDT for hypervisor callback.
> > +        */
> > +       alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
> hyperv_callback_vector);
> > +#endif
> >  }
> >
> >  const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
> > @@ -85,3 +96,36 @@ const __refconst struct hypervisor_x86
> x86_hyper_ms_hyperv = {
> >         .init_platform          = ms_hyperv_init_platform,
> >  };
> >  EXPORT_SYMBOL(x86_hyper_ms_hyperv);
> > +
> > +#if IS_ENABLED(CONFIG_HYPERV)
> > +static int vmbus_irq = -1;
> > +static irq_handler_t vmbus_isr;
> > +
> > +void hv_register_vmbus_handler(int irq, irq_handler_t handler)
> > +{
> > +       vmbus_irq = irq;
> > +       vmbus_isr = handler;
> > +}
> > +
> > +void hyperv_vector_handler(struct pt_regs *regs)
> > +{
> > +       struct pt_regs *old_regs = set_irq_regs(regs);
> > +       struct irq_desc *desc;
> > +
> > +       irq_enter();
> > +       exit_idle();
> > +
> > +       desc = irq_to_desc(vmbus_irq);
> > +
> > +       if (desc)
> > +               generic_handle_irq_desc(vmbus_irq, desc);
> > +
> > +       irq_exit();
> > +       set_irq_regs(old_regs);
> > +}
> > +#else
> > +void hv_register_vmbus_handler(int irq, irq_handler_t handler)
> > +{
> > +}
> > +#endif
> > +EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
> > diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> > index 6ed91d9..8831176 100644
> > --- a/arch/x86/kernel/entry_32.S
> > +++ b/arch/x86/kernel/entry_32.S
> > @@ -1091,11 +1091,18 @@ ENTRY(xen_failsafe_callback)
> >         _ASM_EXTABLE(4b,9b)
> >  ENDPROC(xen_failsafe_callback)
> >
> > -BUILD_INTERRUPT3(xen_hvm_callback_vector,
> XEN_HVM_EVTCHN_CALLBACK,
> > +BUILD_INTERRUPT3(xen_hvm_callback_vector,
> HYPERVISOR_CALLBACK_VECTOR,
> >                 xen_evtchn_do_upcall)
> >
> >  #endif /* CONFIG_XEN */
> >
> > +#if IS_ENABLED(CONFIG_HYPERV)
> > +
> > +BUILD_INTERRUPT3(hyperv_callback_vector,
> HYPERVISOR_CALLBACK_VECTOR,
> > +       hyperv_vector_handler)
> > +
> > +#endif /* CONFIG_HYPERV */
> > +
> >  #ifdef CONFIG_FUNCTION_TRACER
> >  #ifdef CONFIG_DYNAMIC_FTRACE
> >
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index cb3c591..048f224 100644
> > --- a/arch/x86/kernel/entry_64.S
> > +++ b/arch/x86/kernel/entry_64.S
> > @@ -1454,11 +1454,16 @@ ENTRY(xen_failsafe_callback)
> >         CFI_ENDPROC
> >  END(xen_failsafe_callback)
> >
> > -apicinterrupt XEN_HVM_EVTCHN_CALLBACK \
> > +apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
> >         xen_hvm_callback_vector xen_evtchn_do_upcall
> >
> >  #endif /* CONFIG_XEN */
> >
> > +#if IS_ENABLED(CONFIG_HYPERV)
> > +apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
> > +       hyperv_callback_vector hyperv_vector_handler
> > +#endif /* CONFIG_HYPERV */
> > +
> 
> so #ifdef CONFIG_HYPERV does not work here?

The issue was that you could turn on CONFIG_HYPERV without enabling 
CONFIG_X86_LOCAL_APIC. Peter fixed it.

Regards,

K. Y
> 
> Yinghai
> 

Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[H. Peter Anvin]

On 02/12/2013 07:32 PM, KY Srinivasan wrote:
>>>
>>> +#if IS_ENABLED(CONFIG_HYPERV)
>>> +apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
>>> +       hyperv_callback_vector hyperv_vector_handler
>>> +#endif /* CONFIG_HYPERV */
>>> +
>>
>> so #ifdef CONFIG_HYPERV does not work here?
>
> The issue was that you could turn on CONFIG_HYPERV without enabling
> CONFIG_X86_LOCAL_APIC. Peter fixed it.
>

He is asking why you are using IS_ENABLED() instead of #ifdef.  The 
difference is that IS_ENABLED() works even for modules.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

RE: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[KY Srinivasan]

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



> -----Original Message-----
> From: H. Peter Anvin [mailto:hpa@zytor.com]
> Sent: Tuesday, February 12, 2013 10:46 PM
> To: KY Srinivasan
> Cc: Yinghai Lu; mingo@kernel.org; linux-kernel@vger.kernel.org;
> tglx@linutronix.de; hpa@linux.intel.com; linux-tip-commits@vger.kernel.org
> Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special
> hypervisor interrupts
> 
> On 02/12/2013 07:32 PM, KY Srinivasan wrote:
> >>>
> >>> +#if IS_ENABLED(CONFIG_HYPERV)
> >>> +apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
> >>> +       hyperv_callback_vector hyperv_vector_handler
> >>> +#endif /* CONFIG_HYPERV */
> >>> +
> >>
> >> so #ifdef CONFIG_HYPERV does not work here?
> >
> > The issue was that you could turn on CONFIG_HYPERV without enabling
> > CONFIG_X86_LOCAL_APIC. Peter fixed it.
> >
> 
> He is asking why you are using IS_ENABLED() instead of #ifdef.  The
> difference is that IS_ENABLED() works even for modules.

My mistake!

K. Y
> 
> 	-hpa
> 
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 
> 

ÿôèº{.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: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[H. Peter Anvin]

On 02/12/2013 07:49 PM, KY Srinivasan wrote:
>>>
>>> The issue was that you could turn on CONFIG_HYPERV without enabling
>>> CONFIG_X86_LOCAL_APIC. Peter fixed it.
>>>
>>
>> He is asking why you are using IS_ENABLED() instead of #ifdef.  The
>> difference is that IS_ENABLED() works even for modules.
>
> My mistake!
>

Well, which one do you need?

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

RE: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[KY Srinivasan]

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



> -----Original Message-----
> From: H. Peter Anvin [mailto:hpa@zytor.com]
> Sent: Tuesday, February 12, 2013 10:55 PM
> To: KY Srinivasan
> Cc: Yinghai Lu; mingo@kernel.org; linux-kernel@vger.kernel.org;
> tglx@linutronix.de; hpa@linux.intel.com; linux-tip-commits@vger.kernel.org
> Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special
> hypervisor interrupts
> 
> On 02/12/2013 07:49 PM, KY Srinivasan wrote:
> >>>
> >>> The issue was that you could turn on CONFIG_HYPERV without enabling
> >>> CONFIG_X86_LOCAL_APIC. Peter fixed it.
> >>>
> >>
> >> He is asking why you are using IS_ENABLED() instead of #ifdef.  The
> >> difference is that IS_ENABLED() works even for modules.
> >
> > My mistake!
> >
> 
> Well, which one do you need?

I chose the IS_ENABLED() because I wanted to cover the case where HYPERV is configured as a module as well.

K. Y
> 
> 	-hpa
> 
> 
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 
> 

ÿôèº{.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: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Yinghai Lu]

On Tue, Feb 12, 2013 at 7:58 PM, KY Srinivasan <kys@microsoft.com> wrote:
>
>
>> -----Original Message-----
>> From: H. Peter Anvin [mailto:hpa@zytor.com]
>> Sent: Tuesday, February 12, 2013 10:55 PM
>> To: KY Srinivasan
>> Cc: Yinghai Lu; mingo@kernel.org; linux-kernel@vger.kernel.org;
>> tglx@linutronix.de; hpa@linux.intel.com; linux-tip-commits@vger.kernel.org
>> Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special
>> hypervisor interrupts
>>
>> On 02/12/2013 07:49 PM, KY Srinivasan wrote:
>> >>>
>> >>> The issue was that you could turn on CONFIG_HYPERV without enabling
>> >>> CONFIG_X86_LOCAL_APIC. Peter fixed it.
>> >>>
>> >>
>> >> He is asking why you are using IS_ENABLED() instead of #ifdef.  The
>> >> difference is that IS_ENABLED() works even for modules.
>> >
>> > My mistake!
>> >
>>
>> Well, which one do you need?
>
> I chose the IS_ENABLED() because I wanted to cover the case where HYPERV is configured as a module as well.
>

ok, so when HYPERV is built as module, actually it is partially module
as it put some code built-in already?
if user never load hyperv, those code will never not be used.

Can those code not be put in module _init function?

Thanks

Yinghai

RE: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[KY Srinivasan]

> -----Original Message-----
> From: yhlu.kernel@gmail.com [mailto:yhlu.kernel@gmail.com] On Behalf Of
> Yinghai Lu
> Sent: Tuesday, February 12, 2013 11:43 PM
> To: KY Srinivasan
> Cc: H. Peter Anvin; mingo@kernel.org; linux-kernel@vger.kernel.org;
> tglx@linutronix.de; hpa@linux.intel.com; linux-tip-commits@vger.kernel.org
> Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special
> hypervisor interrupts
> 
> On Tue, Feb 12, 2013 at 7:58 PM, KY Srinivasan <kys@microsoft.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: H. Peter Anvin [mailto:hpa@zytor.com]
> >> Sent: Tuesday, February 12, 2013 10:55 PM
> >> To: KY Srinivasan
> >> Cc: Yinghai Lu; mingo@kernel.org; linux-kernel@vger.kernel.org;
> >> tglx@linutronix.de; hpa@linux.intel.com; linux-tip-commits@vger.kernel.org
> >> Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special
> >> hypervisor interrupts
> >>
> >> On 02/12/2013 07:49 PM, KY Srinivasan wrote:
> >> >>>
> >> >>> The issue was that you could turn on CONFIG_HYPERV without enabling
> >> >>> CONFIG_X86_LOCAL_APIC. Peter fixed it.
> >> >>>
> >> >>
> >> >> He is asking why you are using IS_ENABLED() instead of #ifdef.  The
> >> >> difference is that IS_ENABLED() works even for modules.
> >> >
> >> > My mistake!
> >> >
> >>
> >> Well, which one do you need?
> >
> > I chose the IS_ENABLED() because I wanted to cover the case where HYPERV is
> configured as a module as well.
> >
> 
> ok, so when HYPERV is built as module, actually it is partially module
> as it put some code built-in already?
> if user never load hyperv, those code will never not be used.
> 
> Can those code not be put in module _init function?

Some code in mshyperv.c is built into the kernel. Registering an IDT entry is dependent on HYPERV drivers being configured - either as modules or built-in.

K. Y
> 
> Thanks
> 
> Yinghai
> 

[tip:x86/hyperv] x86: Hyper-V: register clocksource only if its advertised

[tip-bot for Olaf Hering]

Commit-ID:  32068f6527b8f1822a30671dedaf59c567325026
Gitweb:     http://git.kernel.org/tip/32068f6527b8f1822a30671dedaf59c567325026
Author:     Olaf Hering <[mailto:olaf@aepfle.de]>
AuthorDate: Sun, 3 Feb 2013 17:22:37 -0800
Committer:  H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Tue, 12 Feb 2013 16:25:48 -0800

x86: Hyper-V: register clocksource only if its advertised

Enable hyperv_clocksource only if its advertised as a feature.
XenServer 6 returns the signature which is checked in
ms_hyperv_platform(), but it does not offer all features. Currently the
clocksource is enabled unconditionally in ms_hyperv_init_platform(), and
the result is a hanging guest.

Hyper-V spec Bit 1 indicates the availability of Partition Reference
Counter.  Register the clocksource only if this bit is set.

The guest in question prints this in dmesg:
 [    0.000000] Hypervisor detected: Microsoft HyperV
 [    0.000000] HyperV: features 0x70, hints 0x0

This bug can be reproduced easily be setting 'viridian=1' in a HVM domU
.cfg file. A workaround without this patch is to boot the HVM guest with
'clocksource=jiffies'.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Link: http://lkml.kernel.org/r/1359940959-32168-1-git-send-email-kys@microsoft.com
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: <stable@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
 arch/x86/kernel/cpu/mshyperv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 0a630dd..646d192 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -68,7 +68,8 @@ static void __init ms_hyperv_init_platform(void)
 	printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
 	       ms_hyperv.features, ms_hyperv.hints);
 
-	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
+	if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
+		clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {

RE: [PATCH 0/3] X86: Deliver Hyper-V interrupts on a seperate IDT vector

[KY Srinivasan]

> -----Original Message-----
> From: K. Y. Srinivasan [mailto:kys@microsoft.com]
> Sent: Sunday, February 03, 2013 8:22 PM
> To: x86@kernel.org; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> JBeulich@suse.com; bp@alien8.de
> Cc: KY Srinivasan
> Subject: [PATCH 0/3] X86: Deliver Hyper-V interrupts on a seperate IDT vector
> 
> This patch-set implements the functionality to deliver Hyper-V VMBUS interrupts
> via
> a special IDT entry. Xen emulates Hyper-V and I have added code in this patch-set
> to
> properly manage this emulation when Linux is running on Hyper-V.
> 
> K. Y. Srinivasan (2):
>   X86: Add a check to catch Xen emulation of Hyper-V
>   X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
> 
> Olaf Hering (1):
>   x86: Hyper-V: register clocksource only if its advertised
> 
>  arch/x86/include/asm/irq_vectors.h |    4 +-
>  arch/x86/include/asm/mshyperv.h    |    4 ++
>  arch/x86/kernel/cpu/mshyperv.c     |   54
> +++++++++++++++++++++++++++++++++++-
>  arch/x86/kernel/entry_32.S         |    9 +++++-
>  arch/x86/kernel/entry_64.S         |    7 ++++-
>  drivers/xen/events.c               |    7 ++--
>  6 files changed, 77 insertions(+), 8 deletions(-)
> 
> --
> 1.7.4.1
> 
> 

Peter,

I have addressed all the comments I have received on these patches. Let me know if there is
something you want me to address before these patches can be checked in.

Regards,

K. Y