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

[PATCH RESEND 1/1] 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.

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     |   39 ++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/entry_32.S         |    9 +++++++-
 arch/x86/kernel/entry_64.S         |    7 +++++-
 drivers/xen/events.c               |    6 ++--
 6 files changed, 62 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
index 1508e51..d09850b 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 0a630dd..3689622 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);
@@ -69,6 +74,11 @@ static void __init ms_hyperv_init_platform(void)
 	       ms_hyperv.features, ms_hyperv.hints);
 
 	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
+
+	/*
+	 * Setup the IDT for hypervisor callback.
+	 */
+	alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, hyperv_callback_vector);
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
@@ -77,3 +87,32 @@ const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
 	.init_platform		= ms_hyperv_init_platform,
 };
 EXPORT_SYMBOL(x86_hyper_ms_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;
+}
+EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
+
+void hyperv_vector_handler(struct pt_regs *regs)
+{
+	struct pt_regs *old_regs = set_irq_regs(regs);
+	struct irq_desc *desc;
+
+	irq_enter();
+#ifdef CONFIG_X86
+	exit_idle();
+#endif
+
+	desc = irq_to_desc(vmbus_irq);
+
+	if (desc)
+		generic_handle_irq_desc(vmbus_irq, desc);
+
+	irq_exit();
+	set_irq_regs(old_regs);
+}
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index e9dd4c4..7d2bb62 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1047,11 +1047,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 1975122..803ca69 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..5c2e92e 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,8 @@ 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

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Jan Beulich]

>>> On 24.01.13 at 02:17, "K. Y. Srinivasan" <kys@microsoft.com> wrote:
> @@ -69,6 +74,11 @@ static void __init ms_hyperv_init_platform(void)
>  	       ms_hyperv.features, ms_hyperv.hints);
>  
>  	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
> +
> +	/*
> +	 * Setup the IDT for hypervisor callback.
> +	 */
> +	alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, hyperv_callback_vector);

Isn't doing this unconditionally here as problematic as the call to
clocksource_register_hz() turned out to be when Xen's Hyper-V
shim reacts to the CPUID inquiry above?

> @@ -77,3 +87,32 @@ const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
>  	.init_platform		= ms_hyperv_init_platform,
>  };
>  EXPORT_SYMBOL(x86_hyper_ms_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;
> +}
> +EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
> +
> +void hyperv_vector_handler(struct pt_regs *regs)
> +{
> +	struct pt_regs *old_regs = set_irq_regs(regs);
> +	struct irq_desc *desc;
> +
> +	irq_enter();
> +#ifdef CONFIG_X86
> +	exit_idle();
> +#endif

This being in a file underneath arch/x86 - why the conditional?

Jan

RE: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[KY Srinivasan]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Thursday, January 24, 2013 3:48 AM
> To: KY Srinivasan
> 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 RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as
> special hypervisor interrupts
> 
> >>> On 24.01.13 at 02:17, "K. Y. Srinivasan" <kys@microsoft.com> wrote:
> > @@ -69,6 +74,11 @@ static void __init ms_hyperv_init_platform(void)
> >  	       ms_hyperv.features, ms_hyperv.hints);
> >
> >  	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
> > +
> > +	/*
> > +	 * Setup the IDT for hypervisor callback.
> > +	 */
> > +	alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
> hyperv_callback_vector);
> 
> Isn't doing this unconditionally here as problematic as the call to
> clocksource_register_hz() turned out to be when Xen's Hyper-V
> shim reacts to the CPUID inquiry above?

I was not sure what to make this conditional on at run-time. To the extent
that Xen emulation of Hyper-V is complete, this will be a problem. Does Xen
return all the "feature bits" of Hyper-V. I could discriminate on a feature that
Xen does not plan to emulate.

> 
> > @@ -77,3 +87,32 @@ const __refconst struct hypervisor_x86
> x86_hyper_ms_hyperv = {
> >  	.init_platform		= ms_hyperv_init_platform,
> >  };
> >  EXPORT_SYMBOL(x86_hyper_ms_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;
> > +}
> > +EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
> > +
> > +void hyperv_vector_handler(struct pt_regs *regs)
> > +{
> > +	struct pt_regs *old_regs = set_irq_regs(regs);
> > +	struct irq_desc *desc;
> > +
> > +	irq_enter();
> > +#ifdef CONFIG_X86
> > +	exit_idle();
> > +#endif
> 
> This being in a file underneath arch/x86 - why the conditional?

Good point, I will fix that.
> 
> Jan
> 
> 

RE: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Jan Beulich]

>>> On 24.01.13 at 17:07, KY Srinivasan <kys@microsoft.com> wrote:

> 
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Thursday, January 24, 2013 3:48 AM
>> To: KY Srinivasan
>> 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 RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as
>> special hypervisor interrupts
>> 
>> >>> On 24.01.13 at 02:17, "K. Y. Srinivasan" <kys@microsoft.com> wrote:
>> > @@ -69,6 +74,11 @@ static void __init ms_hyperv_init_platform(void)
>> >  	       ms_hyperv.features, ms_hyperv.hints);
>> >
>> >  	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
>> > +
>> > +	/*
>> > +	 * Setup the IDT for hypervisor callback.
>> > +	 */
>> > +	alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
>> hyperv_callback_vector);
>> 
>> Isn't doing this unconditionally here as problematic as the call to
>> clocksource_register_hz() turned out to be when Xen's Hyper-V
>> shim reacts to the CPUID inquiry above?
> 
> I was not sure what to make this conditional on at run-time. To the extent
> that Xen emulation of Hyper-V is complete, this will be a problem. Does Xen
> return all the "feature bits" of Hyper-V. I could discriminate on a feature 
> that
> Xen does not plan to emulate.

I've no idea what plans there might be, but that's the code
there is currently:

int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
                          unsigned int *ebx, unsigned int *ecx,
                          unsigned int *edx)
{
    struct domain *d = current->domain;

    if ( !is_viridian_domain(d) )
        return 0;

    leaf -= 0x40000000;
    if ( leaf > 6 )
        return 0;

    *eax = *ebx = *ecx = *edx = 0;
    switch ( leaf )
    {
    case 0:
        *eax = 0x40000006; /* Maximum leaf */
        *ebx = 0x7263694d; /* Magic numbers  */
        *ecx = 0x666F736F;
        *edx = 0x76482074;
        break;
    case 1:
        *eax = 0x31237648; /* Version number */
        break;
    case 2:
        /* Hypervisor information, but only if the guest has set its
           own version number. */
        if ( d->arch.hvm_domain.viridian.guest_os_id.raw == 0 )
            break;
        *eax = 1; /* Build number */
        *ebx = (xen_major_version() << 16) | xen_minor_version();
        *ecx = 0; /* SP */
        *edx = 0; /* Service branch and number */
        break;
    case 3:
        /* Which hypervisor MSRs are available to the guest */
        *eax = (CPUID3A_MSR_APIC_ACCESS |
                CPUID3A_MSR_HYPERCALL   |
                CPUID3A_MSR_VP_INDEX);
        break;
    case 4:
        /* Recommended hypercall usage. */
        if ( (d->arch.hvm_domain.viridian.guest_os_id.raw == 0) ||
             (d->arch.hvm_domain.viridian.guest_os_id.fields.os < 4) )
            break;
        *eax = (CPUID4A_MSR_BASED_APIC |
                CPUID4A_RELAX_TIMER_INT);
        *ebx = 2047; /* long spin count */
        break;
    }

    return 1;
}

Question is - considering you stated that this is supported
starting in Win8, doesn't Hyper-V itself announce that
capability in some explicit way?

Jan

RE: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[KY Srinivasan]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Thursday, January 24, 2013 11:16 AM
> To: KY Srinivasan
> 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 RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as
> special hypervisor interrupts
> 
> >>> On 24.01.13 at 17:07, KY Srinivasan <kys@microsoft.com> wrote:
> 
> >
> >> -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Thursday, January 24, 2013 3:48 AM
> >> To: KY Srinivasan
> >> 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 RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as
> >> special hypervisor interrupts
> >>
> >> >>> On 24.01.13 at 02:17, "K. Y. Srinivasan" <kys@microsoft.com> wrote:
> >> > @@ -69,6 +74,11 @@ static void __init ms_hyperv_init_platform(void)
> >> >  	       ms_hyperv.features, ms_hyperv.hints);
> >> >
> >> >  	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
> >> > +
> >> > +	/*
> >> > +	 * Setup the IDT for hypervisor callback.
> >> > +	 */
> >> > +	alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
> >> hyperv_callback_vector);
> >>
> >> Isn't doing this unconditionally here as problematic as the call to
> >> clocksource_register_hz() turned out to be when Xen's Hyper-V
> >> shim reacts to the CPUID inquiry above?
> >
> > I was not sure what to make this conditional on at run-time. To the extent
> > that Xen emulation of Hyper-V is complete, this will be a problem. Does Xen
> > return all the "feature bits" of Hyper-V. I could discriminate on a feature
> > that
> > Xen does not plan to emulate.
> 
> I've no idea what plans there might be, but that's the code
> there is currently:
> 
> int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
>                           unsigned int *ebx, unsigned int *ecx,
>                           unsigned int *edx)
> {
>     struct domain *d = current->domain;
> 
>     if ( !is_viridian_domain(d) )
>         return 0;
> 
>     leaf -= 0x40000000;
>     if ( leaf > 6 )
>         return 0;
> 
>     *eax = *ebx = *ecx = *edx = 0;
>     switch ( leaf )
>     {
>     case 0:
>         *eax = 0x40000006; /* Maximum leaf */
>         *ebx = 0x7263694d; /* Magic numbers  */
>         *ecx = 0x666F736F;
>         *edx = 0x76482074;
>         break;
>     case 1:
>         *eax = 0x31237648; /* Version number */
>         break;
>     case 2:
>         /* Hypervisor information, but only if the guest has set its
>            own version number. */
>         if ( d->arch.hvm_domain.viridian.guest_os_id.raw == 0 )
>             break;
>         *eax = 1; /* Build number */
>         *ebx = (xen_major_version() << 16) | xen_minor_version();
>         *ecx = 0; /* SP */
>         *edx = 0; /* Service branch and number */
>         break;
>     case 3:
>         /* Which hypervisor MSRs are available to the guest */
>         *eax = (CPUID3A_MSR_APIC_ACCESS |
>                 CPUID3A_MSR_HYPERCALL   |
>                 CPUID3A_MSR_VP_INDEX);
>         break;
>     case 4:
>         /* Recommended hypercall usage. */
>         if ( (d->arch.hvm_domain.viridian.guest_os_id.raw == 0) ||
>              (d->arch.hvm_domain.viridian.guest_os_id.fields.os < 4) )
>             break;
>         *eax = (CPUID4A_MSR_BASED_APIC |
>                 CPUID4A_RELAX_TIMER_INT);
>         *ebx = 2047; /* long spin count */
>         break;
>     }
> 
>     return 1;
> }
> 
> Question is - considering you stated that this is supported
> starting in Win8, doesn't Hyper-V itself announce that
> capability in some explicit way?

Thanks Jan. Unfortunately I don't think tis interrupt delivery model is
specified via a "feature" bit (I will check with the Windows guys). Perhaps, we
can have a Hyper-V specific compilation switch to address the Xen emulation issue.

Regards,

K. Y  
> 
> Jan
> 
> 

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Olaf Hering]

On Thu, Jan 24, KY Srinivasan wrote:


> > Question is - considering you stated that this is supported
> > starting in Win8, doesn't Hyper-V itself announce that
> > capability in some explicit way?
> 
> Thanks Jan. Unfortunately I don't think tis interrupt delivery model
> is specified via a "feature" bit (I will check with the Windows guys).
> Perhaps, we can have a Hyper-V specific compilation switch to address
> the Xen emulation issue.

Would that really help if both pvops XEN_PVHVM and HYPERV are enabled in
the config? I assume at this point the access to the DMI data is not yet
possible.

Olaf

RE: [PATCH RESEND 1/1] 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: 1344 bytes --]



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Thursday, January 24, 2013 2:00 PM
> To: KY Srinivasan
> Cc: Jan Beulich; 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 RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as
> special hypervisor interrupts
> 
> On Thu, Jan 24, KY Srinivasan wrote:
> 
> 
> > > Question is - considering you stated that this is supported
> > > starting in Win8, doesn't Hyper-V itself announce that
> > > capability in some explicit way?
> >
> > Thanks Jan. Unfortunately I don't think tis interrupt delivery model
> > is specified via a "feature" bit (I will check with the Windows guys).
> > Perhaps, we can have a Hyper-V specific compilation switch to address
> > the Xen emulation issue.
> 
> Would that really help if both pvops XEN_PVHVM and HYPERV are enabled in
> the config? I assume at this point the access to the DMI data is not yet
> possible.

I was under the impression that only Dom0 Xen would emulate Hyper-V.


K. Y
> 
> Olaf
> 

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

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[H. Peter Anvin]

Can't you discover Xen emulation by looking for Xen first?  Or does Xen go "stealth"?

Olaf Hering <olaf@aepfle.de> wrote:

>On Thu, Jan 24, KY Srinivasan wrote:
>
>
>> > Question is - considering you stated that this is supported
>> > starting in Win8, doesn't Hyper-V itself announce that
>> > capability in some explicit way?
>> 
>> Thanks Jan. Unfortunately I don't think tis interrupt delivery model
>> is specified via a "feature" bit (I will check with the Windows
>guys).
>> Perhaps, we can have a Hyper-V specific compilation switch to address
>> the Xen emulation issue.
>
>Would that really help if both pvops XEN_PVHVM and HYPERV are enabled
>in
>the config? I assume at this point the access to the DMI data is not
>yet
>possible.
>
>Olaf

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

RE: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[H. Peter Anvin]

I also have to point out the obvious problem with Xen masquerading as HyperV without implementing the same feature set...

KY Srinivasan <kys@microsoft.com> wrote:

>
>
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Thursday, January 24, 2013 11:16 AM
>> To: KY Srinivasan
>> 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 RESEND 1/1] X86: Handle Hyper-V vmbus interrupts
>as
>> special hypervisor interrupts
>> 
>> >>> On 24.01.13 at 17:07, KY Srinivasan <kys@microsoft.com> wrote:
>> 
>> >
>> >> -----Original Message-----
>> >> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >> Sent: Thursday, January 24, 2013 3:48 AM
>> >> To: KY Srinivasan
>> >> 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 RESEND 1/1] X86: Handle Hyper-V vmbus
>interrupts as
>> >> special hypervisor interrupts
>> >>
>> >> >>> On 24.01.13 at 02:17, "K. Y. Srinivasan" <kys@microsoft.com>
>wrote:
>> >> > @@ -69,6 +74,11 @@ static void __init
>ms_hyperv_init_platform(void)
>> >> >  	       ms_hyperv.features, ms_hyperv.hints);
>> >> >
>> >> >  	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
>> >> > +
>> >> > +	/*
>> >> > +	 * Setup the IDT for hypervisor callback.
>> >> > +	 */
>> >> > +	alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
>> >> hyperv_callback_vector);
>> >>
>> >> Isn't doing this unconditionally here as problematic as the call
>to
>> >> clocksource_register_hz() turned out to be when Xen's Hyper-V
>> >> shim reacts to the CPUID inquiry above?
>> >
>> > I was not sure what to make this conditional on at run-time. To the
>extent
>> > that Xen emulation of Hyper-V is complete, this will be a problem.
>Does Xen
>> > return all the "feature bits" of Hyper-V. I could discriminate on a
>feature
>> > that
>> > Xen does not plan to emulate.
>> 
>> I've no idea what plans there might be, but that's the code
>> there is currently:
>> 
>> int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
>>                           unsigned int *ebx, unsigned int *ecx,
>>                           unsigned int *edx)
>> {
>>     struct domain *d = current->domain;
>> 
>>     if ( !is_viridian_domain(d) )
>>         return 0;
>> 
>>     leaf -= 0x40000000;
>>     if ( leaf > 6 )
>>         return 0;
>> 
>>     *eax = *ebx = *ecx = *edx = 0;
>>     switch ( leaf )
>>     {
>>     case 0:
>>         *eax = 0x40000006; /* Maximum leaf */
>>         *ebx = 0x7263694d; /* Magic numbers  */
>>         *ecx = 0x666F736F;
>>         *edx = 0x76482074;
>>         break;
>>     case 1:
>>         *eax = 0x31237648; /* Version number */
>>         break;
>>     case 2:
>>         /* Hypervisor information, but only if the guest has set its
>>            own version number. */
>>         if ( d->arch.hvm_domain.viridian.guest_os_id.raw == 0 )
>>             break;
>>         *eax = 1; /* Build number */
>>         *ebx = (xen_major_version() << 16) | xen_minor_version();
>>         *ecx = 0; /* SP */
>>         *edx = 0; /* Service branch and number */
>>         break;
>>     case 3:
>>         /* Which hypervisor MSRs are available to the guest */
>>         *eax = (CPUID3A_MSR_APIC_ACCESS |
>>                 CPUID3A_MSR_HYPERCALL   |
>>                 CPUID3A_MSR_VP_INDEX);
>>         break;
>>     case 4:
>>         /* Recommended hypercall usage. */
>>         if ( (d->arch.hvm_domain.viridian.guest_os_id.raw == 0) ||
>>              (d->arch.hvm_domain.viridian.guest_os_id.fields.os < 4)
>)
>>             break;
>>         *eax = (CPUID4A_MSR_BASED_APIC |
>>                 CPUID4A_RELAX_TIMER_INT);
>>         *ebx = 2047; /* long spin count */
>>         break;
>>     }
>> 
>>     return 1;
>> }
>> 
>> Question is - considering you stated that this is supported
>> starting in Win8, doesn't Hyper-V itself announce that
>> capability in some explicit way?
>
>Thanks Jan. Unfortunately I don't think tis interrupt delivery model is
>specified via a "feature" bit (I will check with the Windows guys).
>Perhaps, we
>can have a Hyper-V specific compilation switch to address the Xen
>emulation issue.
>
>Regards,
>
>K. Y  
>> 
>> Jan
>> 
>> 

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

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Olaf Hering]

On Thu, Jan 24, H. Peter Anvin wrote:

> Can't you discover Xen emulation by looking for Xen first?  Or does Xen go "stealth"?

The current code looks at cpuid to decide what the host type is. One
thing to detect a Xen host is to look for the DIM strings, which still
have "Xen HVM DomU" or similar.

Olaf

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[H. Peter Anvin]

And there is no evidence of Xen in CPUID?

Olaf Hering <olaf@aepfle.de> wrote:

>On Thu, Jan 24, H. Peter Anvin wrote:
>
>> Can't you discover Xen emulation by looking for Xen first?  Or does
>Xen go "stealth"?
>
>The current code looks at cpuid to decide what the host type is. One
>thing to detect a Xen host is to look for the DIM strings, which still
>have "Xen HVM DomU" or similar.
>
>Olaf

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

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Jan Beulich]

>>> On 24.01.13 at 20:04, "H. Peter Anvin" <hpa@zytor.com> wrote:
> Can't you discover Xen emulation by looking for Xen first?  Or does Xen go 
> "stealth"?

That's already being done - the ordering currently is Xen, VMWare,
Hyper-V, KVM. I.e. there's only a problem when !CONFIG_XEN_PVHVM.

Jan

RE: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Jan Beulich]

>>> On 24.01.13 at 20:10, "H. Peter Anvin" <hpa@zytor.com> wrote:
> I also have to point out the obvious problem with Xen masquerading as HyperV 
> without implementing the same feature set...

I can't resist to state that this is what feature bits have been
introduced for in CPUID leaves. As long as Xen's shim doesn't
advertise a feature bit it doesn't implement, all should be fine.

Jan

RE: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Jan Beulich]

>>> On 24.01.13 at 20:03, KY Srinivasan <kys@microsoft.com> wrote:
> I was under the impression that only Dom0 Xen would emulate Hyper-V.

How that? It's the hypervisor that does the emulation, and obviously
not for Dom0, but for (HVM) DomU-s.

Jan

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Jan Beulich]

>>> On 24.01.13 at 19:59, Olaf Hering <olaf@aepfle.de> wrote:
> On Thu, Jan 24, KY Srinivasan wrote:
> 
> 
>> > Question is - considering you stated that this is supported
>> > starting in Win8, doesn't Hyper-V itself announce that
>> > capability in some explicit way?
>> 
>> Thanks Jan. Unfortunately I don't think tis interrupt delivery model
>> is specified via a "feature" bit (I will check with the Windows guys).
>> Perhaps, we can have a Hyper-V specific compilation switch to address
>> the Xen emulation issue.
> 
> Would that really help if both pvops XEN_PVHVM and HYPERV are enabled in
> the config? I assume at this point the access to the DMI data is not yet
> possible.

As just said in another reply - with XEN_PVHVM, there's no problem,
since Xen gets checked for first. There's only a problem when
!XEN_PVHVM, because in that case Hyper-V will be probed for.
And the problem can only get bigger when on top of that the
out-of-tree PV drivers are intended to be used.

Jan

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Olaf Hering]

On Fri, Jan 25, Jan Beulich wrote:

> >>> On 24.01.13 at 19:59, Olaf Hering <olaf@aepfle.de> wrote:
> > On Thu, Jan 24, KY Srinivasan wrote:
> > 
> > 
> >> > Question is - considering you stated that this is supported
> >> > starting in Win8, doesn't Hyper-V itself announce that
> >> > capability in some explicit way?
> >> 
> >> Thanks Jan. Unfortunately I don't think tis interrupt delivery model
> >> is specified via a "feature" bit (I will check with the Windows guys).
> >> Perhaps, we can have a Hyper-V specific compilation switch to address
> >> the Xen emulation issue.
> > 
> > Would that really help if both pvops XEN_PVHVM and HYPERV are enabled in
> > the config? I assume at this point the access to the DMI data is not yet
> > possible.
> 
> As just said in another reply - with XEN_PVHVM, there's no problem,
> since Xen gets checked for first. There's only a problem when
> !XEN_PVHVM, because in that case Hyper-V will be probed for.
> And the problem can only get bigger when on top of that the
> out-of-tree PV drivers are intended to be used.

Yes, xen_cpuid_base() recognizes Xen as hypervisor even with
'viridian=1' in the .cfg file.
 I think if there is no feature bit for this, the DMI can be used
because its appearently available before the host is checked:

...
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] DMI: Xen HVM domU, BIOS 4.1.3_06-0.7.1 12/05/2012
[    0.000000] Hypervisor detected: Microsoft HyperV
[    0.000000] HyperV: features 0x70, hints 0x0
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
...

Olaf

RE: [PATCH RESEND 1/1] 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: 2586 bytes --]



> -----Original Message-----
> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Thursday, January 24, 2013 4:28 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
> Subject: Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as
> special hypervisor interrupts
> 
> On Wed, Jan 23, 2013 at 05:56:09PM -0800, K. Y. Srinivasan wrote:
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index 1975122..803ca69 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 */
> 
> arch/x86/built-in.o: In function `_set_gate':
> /w/kernel/linux-2.6/arch/x86/include/asm/desc.h:328: undefined reference to
> `hyperv_callback_vector'
> make: *** [vmlinux] Error 1
> 
> because, of course:
> 
> # CONFIG_HYPERV is not set

My mistake. I should have properly guarded code that needs to be conditional. This also would address
the issue that Jan raised. I will resend this patch soon.

Regards,

K. Y 

> 
> But, I have a more serious pet-peeve with the whole hypervisors
> detection stuff: we're building arch/x86/kernel/cpu/hypervisor.c
> unconditionally and yet, we have CONFIG_PARAVIRT_GUEST to ask the user
> whether she wants to enable some options for running linux as a guest.
> 
> And actually, it would be better to put all that virt-related stuff
> under a config option called HYPERVISOR or whatever, under "Processor
> type and features" which opens a menu with all virt stuff for people and
> distros to select.
> 
> This way, init_hypervisor_platform and the rest of hypervisors stuff
> won't run needlessly on baremetal and setups who don't want that.
> 
> Any non-starter reasons for not doing that?


> 
> --
> Regards/Gruss,
>     Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --
> 

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

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[H. Peter Anvin]

On 01/24/2013 11:35 AM, Borislav Petkov wrote:
> On Thu, Jan 24, 2013 at 06:11:32AM -0600, H. Peter Anvin wrote:
>> Sounds great in theory at least, as long as it doesn't mean pushing a
>> bunch of #ifdefs into other code.
> 
> Just one set in hypervisor.h but this is the RightWay™ we do it in the
> kernel :-).
> 
> Anyway, it turned out to be easier than I thought, just two patches
> which I'll be sending as a reply to this message. I'll run more
> randconfig tests on them, anyone sees issues please let me know.
> 

Awesome :)

	-hpa

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Borislav Petkov]

On Thu, Jan 24, 2013 at 06:11:32AM -0600, H. Peter Anvin wrote:
> Sounds great in theory at least, as long as it doesn't mean pushing a
> bunch of #ifdefs into other code.

Just one set in hypervisor.h but this is the RightWay™ we do it in the
kernel :-).

Anyway, it turned out to be easier than I thought, just two patches
which I'll be sending as a reply to this message. I'll run more
randconfig tests on them, anyone sees issues please let me know.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[H. Peter Anvin]

Sounds great in theory at least, as long as it doesn't mean pushing a bunch of #ifdefs into other code.

Borislav Petkov <bp@alien8.de> wrote:

>On Wed, Jan 23, 2013 at 05:56:09PM -0800, K. Y. Srinivasan wrote:
>> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
>> index 1975122..803ca69 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 */
>
>arch/x86/built-in.o: In function `_set_gate':
>/w/kernel/linux-2.6/arch/x86/include/asm/desc.h:328: undefined
>reference to `hyperv_callback_vector'
>make: *** [vmlinux] Error 1
>
>because, of course:
>
># CONFIG_HYPERV is not set
>
>But, I have a more serious pet-peeve with the whole hypervisors
>detection stuff: we're building arch/x86/kernel/cpu/hypervisor.c
>unconditionally and yet, we have CONFIG_PARAVIRT_GUEST to ask the user
>whether she wants to enable some options for running linux as a guest.
>
>And actually, it would be better to put all that virt-related stuff
>under a config option called HYPERVISOR or whatever, under "Processor
>type and features" which opens a menu with all virt stuff for people
>and
>distros to select.
>
>This way, init_hypervisor_platform and the rest of hypervisors stuff
>won't run needlessly on baremetal and setups who don't want that.
>
>Any non-starter reasons for not doing that?

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

Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[Borislav Petkov]

On Wed, Jan 23, 2013 at 05:56:09PM -0800, K. Y. Srinivasan wrote:
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index 1975122..803ca69 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 */

arch/x86/built-in.o: In function `_set_gate':
/w/kernel/linux-2.6/arch/x86/include/asm/desc.h:328: undefined reference to `hyperv_callback_vector'
make: *** [vmlinux] Error 1

because, of course:

# CONFIG_HYPERV is not set

But, I have a more serious pet-peeve with the whole hypervisors
detection stuff: we're building arch/x86/kernel/cpu/hypervisor.c
unconditionally and yet, we have CONFIG_PARAVIRT_GUEST to ask the user
whether she wants to enable some options for running linux as a guest.

And actually, it would be better to put all that virt-related stuff
under a config option called HYPERVISOR or whatever, under "Processor
type and features" which opens a menu with all virt stuff for people and
distros to select.

This way, init_hypervisor_platform and the rest of hypervisors stuff
won't run needlessly on baremetal and setups who don't want that.

Any non-starter reasons for not doing that?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[PATCH RESEND 1/1] 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.

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     |   39 ++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/entry_32.S         |    9 +++++++-
 arch/x86/kernel/entry_64.S         |    7 +++++-
 drivers/xen/events.c               |    6 ++--
 6 files changed, 62 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
index 1508e51..d09850b 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 0a630dd..3689622 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);
@@ -69,6 +74,11 @@ static void __init ms_hyperv_init_platform(void)
 	       ms_hyperv.features, ms_hyperv.hints);
 
 	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
+
+	/*
+	 * Setup the IDT for hypervisor callback.
+	 */
+	alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, hyperv_callback_vector);
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
@@ -77,3 +87,32 @@ const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
 	.init_platform		= ms_hyperv_init_platform,
 };
 EXPORT_SYMBOL(x86_hyper_ms_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;
+}
+EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
+
+void hyperv_vector_handler(struct pt_regs *regs)
+{
+	struct pt_regs *old_regs = set_irq_regs(regs);
+	struct irq_desc *desc;
+
+	irq_enter();
+#ifdef CONFIG_X86
+	exit_idle();
+#endif
+
+	desc = irq_to_desc(vmbus_irq);
+
+	if (desc)
+		generic_handle_irq_desc(vmbus_irq, desc);
+
+	irq_exit();
+	set_irq_regs(old_regs);
+}
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index e9dd4c4..7d2bb62 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1047,11 +1047,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 1975122..803ca69 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..5c2e92e 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,8 @@ 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

[PATCH RESEND 1/1] 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.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 arch/x86/include/asm/irq_vectors.h |    2 +
 arch/x86/include/asm/mshyperv.h    |    4 +++
 arch/x86/kernel/cpu/mshyperv.c     |   39 ++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/entry_32.S         |    7 ++++++
 arch/x86/kernel/entry_64.S         |    5 ++++
 5 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
index 1508e51..c2ff239 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -112,6 +112,8 @@
 /* Xen vector callback to receive events in a HVM domain */
 #define XEN_HVM_EVTCHN_CALLBACK		0xf3
 
+/* Hyper-V vector callback to receive vmbus interrupts*/
+#define HYPER_V_CALLBACK_VECTOR		0xf2
 /*
  * Local APIC timer IRQ vector is on a different priority level,
  * to work around the 'lost local interrupt if more than 2 IRQ
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 0a630dd..03be583 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);
@@ -69,6 +74,11 @@ static void __init ms_hyperv_init_platform(void)
 	       ms_hyperv.features, ms_hyperv.hints);
 
 	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
+
+	/*
+	 * Setup the IDT for hypervisor callback.
+	 */
+	alloc_intr_gate(HYPER_V_CALLBACK_VECTOR, hyperv_callback_vector);
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
@@ -77,3 +87,32 @@ const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
 	.init_platform		= ms_hyperv_init_platform,
 };
 EXPORT_SYMBOL(x86_hyper_ms_hyperv);
+
+static int vmbus_irq;
+static irq_handler_t vmbus_isr;
+
+void hv_register_vmbus_handler(int irq, irq_handler_t handler)
+{
+	vmbus_irq = irq;
+	vmbus_isr = handler;
+}
+EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
+
+void hyperv_vector_handler(struct pt_regs *regs)
+{
+	struct pt_regs *old_regs = set_irq_regs(regs);
+	struct irq_desc *desc;
+
+	irq_enter();
+#ifdef CONFIG_X86
+	exit_idle();
+#endif
+
+	desc = irq_to_desc(vmbus_irq);
+
+	if (desc)
+		generic_handle_irq_desc(vmbus_irq, desc);
+
+	irq_exit();
+	set_irq_regs(old_regs);
+}
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index e9dd4c4..7743876 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1052,6 +1052,13 @@ BUILD_INTERRUPT3(xen_hvm_callback_vector, XEN_HVM_EVTCHN_CALLBACK,
 
 #endif	/* CONFIG_XEN */
 
+#if IS_ENABLED(CONFIG_HYPERV)
+
+BUILD_INTERRUPT3(hyperv_callback_vector, HYPER_V_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 1975122..a1cb724 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1451,6 +1451,11 @@ apicinterrupt XEN_HVM_EVTCHN_CALLBACK \
 
 #endif /* CONFIG_XEN */
 
+#if IS_ENABLED(CONFIG_HYPERV)
+apicinterrupt HYPER_V_CALLBACK_VECTOR \
+	hyperv_callback_vector hyperv_vector_handler
+#endif /* CONFIG_HYPERV */
+
 /*
  * Some functions should be protected against kprobes
  */
-- 
1.7.4.1