* [PATCH] xen: implement vector callback for evtchn delivery
@ 2010-05-18 10:31 Stefano Stabellini
2010-05-24 18:59 ` Keir Fraser
0 siblings, 1 reply; 25+ messages in thread
From: Stefano Stabellini @ 2010-05-18 10:31 UTC (permalink / raw)
To: xen-devel
Hi all,
this patch implements the vector callback mechanism in Xen and it is based
on Sheng's work so he should be considered the original author.
This update addresses Jan's comment about the test v->vcpu_id != 0 in
hvm_assert_evtchn_irq.
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -185,16 +185,16 @@
void hvm_assert_evtchn_irq(struct vcpu *v)
{
- if ( v->vcpu_id != 0 )
- return;
-
if ( unlikely(in_irq() || !local_irq_is_enabled()) )
{
tasklet_schedule(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
return;
}
- hvm_set_callback_irq_level(v);
+ if ( is_hvm_pv_evtchn_vcpu(v) )
+ vcpu_kick(v);
+ else if ( v->vcpu_id == 0 )
+ hvm_set_callback_irq_level(v);
}
void hvm_set_pci_link_route(struct domain *d, u8 link, u8 isa_irq)
@@ -251,7 +251,7 @@
via_type = (uint8_t)(via >> 56) + 1;
if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
- (via_type > HVMIRQ_callback_pci_intx) )
+ (via_type > HVMIRQ_callback_vector) )
via_type = HVMIRQ_callback_none;
spin_lock(&d->arch.hvm_domain.irq_lock);
@@ -297,6 +297,9 @@
if ( hvm_irq->callback_via_asserted )
__hvm_pci_intx_assert(d, pdev, pintx);
break;
+ case HVMIRQ_callback_vector:
+ hvm_irq->callback_via.vector = (uint8_t)via;
+ break;
default:
break;
}
@@ -312,6 +315,10 @@
case HVMIRQ_callback_pci_intx:
printk("PCI INTx Dev 0x%02x Int%c\n", pdev, 'A' + pintx);
break;
+ case HVMIRQ_callback_vector:
+ printk("Set HVMIRQ_callback_vector to %u\n",
+ hvm_irq->callback_via.vector);
+ break;
default:
printk("None\n");
break;
@@ -323,6 +330,10 @@
struct hvm_domain *plat = &v->domain->arch.hvm_domain;
int vector;
+ if (plat->irq.callback_via_type == HVMIRQ_callback_vector &&
+ vcpu_info(v, evtchn_upcall_pending))
+ return hvm_intack_vector(plat->irq.callback_via.vector);
+
if ( unlikely(v->nmi_pending) )
return hvm_intack_nmi;
@@ -363,6 +374,8 @@
case hvm_intsrc_lapic:
if ( !vlapic_ack_pending_irq(v, intack.vector) )
intack = hvm_intack_none;
+ break;
+ case hvm_intsrc_vector:
break;
default:
intack = hvm_intack_none;
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -164,7 +164,8 @@
{
HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
vmx_inject_extint(intack.vector);
- pt_intr_post(v, intack);
+ if (intack.source != hvm_intsrc_vector)
+ pt_intr_post(v, intack);
}
/* Is there another IRQ to queue up behind this one? */
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -260,7 +260,10 @@
(1U << XENFEAT_highmem_assist) |
(1U << XENFEAT_gnttab_map_avail_bits);
else
+ {
fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
+ fi.submap |= (1U << XENFEAT_hvm_callback_vector);
+ }
#endif
break;
default:
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -33,7 +33,8 @@
hvm_intsrc_pic,
hvm_intsrc_lapic,
hvm_intsrc_nmi,
- hvm_intsrc_mce
+ hvm_intsrc_mce,
+ hvm_intsrc_vector
};
struct hvm_intack {
uint8_t source; /* enum hvm_intsrc */
@@ -44,6 +45,7 @@
#define hvm_intack_lapic(vec) ( (struct hvm_intack) { hvm_intsrc_lapic, vec } )
#define hvm_intack_nmi ( (struct hvm_intack) { hvm_intsrc_nmi, 2 } )
#define hvm_intack_mce ( (struct hvm_intack) { hvm_intsrc_mce, 18 } )
+#define hvm_intack_vector(vec)( (struct hvm_intack) { hvm_intsrc_vector, vec } )
enum hvm_intblk {
hvm_intblk_none, /* not blocked (deliverable) */
hvm_intblk_shadow, /* MOV-SS or STI shadow */
diff --git a/xen/include/asm-x86/hvm/irq.h b/xen/include/asm-x86/hvm/irq.h
--- a/xen/include/asm-x86/hvm/irq.h
+++ b/xen/include/asm-x86/hvm/irq.h
@@ -54,12 +54,14 @@
enum {
HVMIRQ_callback_none,
HVMIRQ_callback_gsi,
- HVMIRQ_callback_pci_intx
+ HVMIRQ_callback_pci_intx,
+ HVMIRQ_callback_vector
} callback_via_type;
};
union {
uint32_t gsi;
struct { uint8_t dev, intx; } pci;
+ uint32_t vector;
} callback_via;
/* Number of INTx wires asserting each PCI-ISA link. */
diff --git a/xen/include/public/features.h b/xen/include/public/features.h
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -68,6 +68,9 @@
*/
#define XENFEAT_gnttab_map_avail_bits 7
+/* x86: Does this Xen host support the HVM callback vector type? */
+#define XENFEAT_hvm_callback_vector 8
+
/* x86: pvclock algorithm is safe to use on HVM */
#define XENFEAT_hvm_safe_pvclock 9
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -606,6 +606,9 @@
#define VM_ASSIST(_d,_t) (test_bit((_t), &(_d)->vm_assist))
#define is_hvm_domain(d) ((d)->is_hvm)
+#define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \
+ d->arch.hvm_domain.irq.callback_via_type == HVMIRQ_callback_vector)
+#define is_hvm_pv_evtchn_vcpu(v) (is_hvm_pv_evtchn_domain(v->domain))
#define is_hvm_vcpu(v) (is_hvm_domain(v->domain))
#define need_iommu(d) ((d)->need_iommu)
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-18 10:31 [PATCH] xen: implement vector callback for evtchn delivery Stefano Stabellini
@ 2010-05-24 18:59 ` Keir Fraser
2010-05-25 9:55 ` Stefano Stabellini
0 siblings, 1 reply; 25+ messages in thread
From: Keir Fraser @ 2010-05-24 18:59 UTC (permalink / raw)
To: Stefano Stabellini, xen-devel@lists.xensource.com
Please add documentation to include/public/hvm/param.h about how to specify
the new callback method, and detect when it is available. Move the new
is_hvm_pv_blah macros out into an appropriate include/asm-x86 header file --
They are not arch independent.
-- Keir
On 18/05/2010 11:31, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
wrote:
> Hi all,
> this patch implements the vector callback mechanism in Xen and it is based
> on Sheng's work so he should be considered the original author.
>
> This update addresses Jan's comment about the test v->vcpu_id != 0 in
> hvm_assert_evtchn_irq.
>
> Signed-off-by: Sheng Yang <sheng@linux.intel.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> ---
>
>
> diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -185,16 +185,16 @@
>
> void hvm_assert_evtchn_irq(struct vcpu *v)
> {
> - if ( v->vcpu_id != 0 )
> - return;
> -
> if ( unlikely(in_irq() || !local_irq_is_enabled()) )
> {
> tasklet_schedule(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
> return;
> }
>
> - hvm_set_callback_irq_level(v);
> + if ( is_hvm_pv_evtchn_vcpu(v) )
> + vcpu_kick(v);
> + else if ( v->vcpu_id == 0 )
> + hvm_set_callback_irq_level(v);
> }
>
> void hvm_set_pci_link_route(struct domain *d, u8 link, u8 isa_irq)
> @@ -251,7 +251,7 @@
>
> via_type = (uint8_t)(via >> 56) + 1;
> if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
> - (via_type > HVMIRQ_callback_pci_intx) )
> + (via_type > HVMIRQ_callback_vector) )
> via_type = HVMIRQ_callback_none;
>
> spin_lock(&d->arch.hvm_domain.irq_lock);
> @@ -297,6 +297,9 @@
> if ( hvm_irq->callback_via_asserted )
> __hvm_pci_intx_assert(d, pdev, pintx);
> break;
> + case HVMIRQ_callback_vector:
> + hvm_irq->callback_via.vector = (uint8_t)via;
> + break;
> default:
> break;
> }
> @@ -312,6 +315,10 @@
> case HVMIRQ_callback_pci_intx:
> printk("PCI INTx Dev 0x%02x Int%c\n", pdev, 'A' + pintx);
> break;
> + case HVMIRQ_callback_vector:
> + printk("Set HVMIRQ_callback_vector to %u\n",
> + hvm_irq->callback_via.vector);
> + break;
> default:
> printk("None\n");
> break;
> @@ -323,6 +330,10 @@
> struct hvm_domain *plat = &v->domain->arch.hvm_domain;
> int vector;
>
> + if (plat->irq.callback_via_type == HVMIRQ_callback_vector &&
> + vcpu_info(v, evtchn_upcall_pending))
> + return hvm_intack_vector(plat->irq.callback_via.vector);
> +
> if ( unlikely(v->nmi_pending) )
> return hvm_intack_nmi;
>
> @@ -363,6 +374,8 @@
> case hvm_intsrc_lapic:
> if ( !vlapic_ack_pending_irq(v, intack.vector) )
> intack = hvm_intack_none;
> + break;
> + case hvm_intsrc_vector:
> break;
> default:
> intack = hvm_intack_none;
> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -164,7 +164,8 @@
> {
> HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
> vmx_inject_extint(intack.vector);
> - pt_intr_post(v, intack);
> + if (intack.source != hvm_intsrc_vector)
> + pt_intr_post(v, intack);
> }
>
> /* Is there another IRQ to queue up behind this one? */
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -260,7 +260,10 @@
> (1U << XENFEAT_highmem_assist) |
> (1U << XENFEAT_gnttab_map_avail_bits);
> else
> + {
> fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
> + fi.submap |= (1U << XENFEAT_hvm_callback_vector);
> + }
> #endif
> break;
> default:
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -33,7 +33,8 @@
> hvm_intsrc_pic,
> hvm_intsrc_lapic,
> hvm_intsrc_nmi,
> - hvm_intsrc_mce
> + hvm_intsrc_mce,
> + hvm_intsrc_vector
> };
> struct hvm_intack {
> uint8_t source; /* enum hvm_intsrc */
> @@ -44,6 +45,7 @@
> #define hvm_intack_lapic(vec) ( (struct hvm_intack) { hvm_intsrc_lapic, vec }
> )
> #define hvm_intack_nmi ( (struct hvm_intack) { hvm_intsrc_nmi, 2 } )
> #define hvm_intack_mce ( (struct hvm_intack) { hvm_intsrc_mce, 18 }
> )
> +#define hvm_intack_vector(vec)( (struct hvm_intack) { hvm_intsrc_vector, vec
> } )
> enum hvm_intblk {
> hvm_intblk_none, /* not blocked (deliverable) */
> hvm_intblk_shadow, /* MOV-SS or STI shadow */
> diff --git a/xen/include/asm-x86/hvm/irq.h b/xen/include/asm-x86/hvm/irq.h
> --- a/xen/include/asm-x86/hvm/irq.h
> +++ b/xen/include/asm-x86/hvm/irq.h
> @@ -54,12 +54,14 @@
> enum {
> HVMIRQ_callback_none,
> HVMIRQ_callback_gsi,
> - HVMIRQ_callback_pci_intx
> + HVMIRQ_callback_pci_intx,
> + HVMIRQ_callback_vector
> } callback_via_type;
> };
> union {
> uint32_t gsi;
> struct { uint8_t dev, intx; } pci;
> + uint32_t vector;
> } callback_via;
>
> /* Number of INTx wires asserting each PCI-ISA link. */
> diff --git a/xen/include/public/features.h b/xen/include/public/features.h
> --- a/xen/include/public/features.h
> +++ b/xen/include/public/features.h
> @@ -68,6 +68,9 @@
> */
> #define XENFEAT_gnttab_map_avail_bits 7
>
> +/* x86: Does this Xen host support the HVM callback vector type? */
> +#define XENFEAT_hvm_callback_vector 8
> +
> /* x86: pvclock algorithm is safe to use on HVM */
> #define XENFEAT_hvm_safe_pvclock 9
>
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -606,6 +606,9 @@
> #define VM_ASSIST(_d,_t) (test_bit((_t), &(_d)->vm_assist))
>
> #define is_hvm_domain(d) ((d)->is_hvm)
> +#define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \
> + d->arch.hvm_domain.irq.callback_via_type == HVMIRQ_callback_vector)
> +#define is_hvm_pv_evtchn_vcpu(v) (is_hvm_pv_evtchn_domain(v->domain))
> #define is_hvm_vcpu(v) (is_hvm_domain(v->domain))
> #define need_iommu(d) ((d)->need_iommu)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-24 18:59 ` Keir Fraser
@ 2010-05-25 9:55 ` Stefano Stabellini
2010-05-26 6:51 ` Boris Derzhavets
0 siblings, 1 reply; 25+ messages in thread
From: Stefano Stabellini @ 2010-05-25 9:55 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel@lists.xensource.com, Stefano Stabellini
On Mon, 24 May 2010, Keir Fraser wrote:
> Please add documentation to include/public/hvm/param.h about how to specify
> the new callback method, and detect when it is available. Move the new
> is_hvm_pv_blah macros out into an appropriate include/asm-x86 header file --
> They are not arch independent.
Done.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
diff -r 12c79a476007 xen/arch/x86/hvm/irq.c
--- a/xen/arch/x86/hvm/irq.c Tue May 25 09:08:34 2010 +0100
+++ b/xen/arch/x86/hvm/irq.c Tue May 25 10:44:07 2010 +0100
@@ -185,16 +185,16 @@
void hvm_assert_evtchn_irq(struct vcpu *v)
{
- if ( v->vcpu_id != 0 )
- return;
-
if ( unlikely(in_irq() || !local_irq_is_enabled()) )
{
tasklet_schedule(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
return;
}
- hvm_set_callback_irq_level(v);
+ if ( is_hvm_pv_evtchn_vcpu(v) )
+ vcpu_kick(v);
+ else if ( v->vcpu_id == 0 )
+ hvm_set_callback_irq_level(v);
}
void hvm_set_pci_link_route(struct domain *d, u8 link, u8 isa_irq)
@@ -251,7 +251,7 @@
via_type = (uint8_t)(via >> 56) + 1;
if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
- (via_type > HVMIRQ_callback_pci_intx) )
+ (via_type > HVMIRQ_callback_vector) )
via_type = HVMIRQ_callback_none;
spin_lock(&d->arch.hvm_domain.irq_lock);
@@ -297,6 +297,9 @@
if ( hvm_irq->callback_via_asserted )
__hvm_pci_intx_assert(d, pdev, pintx);
break;
+ case HVMIRQ_callback_vector:
+ hvm_irq->callback_via.vector = (uint8_t)via;
+ break;
default:
break;
}
@@ -312,6 +315,10 @@
case HVMIRQ_callback_pci_intx:
printk("PCI INTx Dev 0x%02x Int%c\n", pdev, 'A' + pintx);
break;
+ case HVMIRQ_callback_vector:
+ printk("Set HVMIRQ_callback_vector to %u\n",
+ hvm_irq->callback_via.vector);
+ break;
default:
printk("None\n");
break;
@@ -323,6 +330,10 @@
struct hvm_domain *plat = &v->domain->arch.hvm_domain;
int vector;
+ if (plat->irq.callback_via_type == HVMIRQ_callback_vector &&
+ vcpu_info(v, evtchn_upcall_pending))
+ return hvm_intack_vector(plat->irq.callback_via.vector);
+
if ( unlikely(v->nmi_pending) )
return hvm_intack_nmi;
@@ -363,6 +374,8 @@
case hvm_intsrc_lapic:
if ( !vlapic_ack_pending_irq(v, intack.vector) )
intack = hvm_intack_none;
+ break;
+ case hvm_intsrc_vector:
break;
default:
intack = hvm_intack_none;
diff -r 12c79a476007 xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c Tue May 25 09:08:34 2010 +0100
+++ b/xen/arch/x86/hvm/vmx/intr.c Tue May 25 10:44:07 2010 +0100
@@ -164,7 +164,8 @@
{
HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
vmx_inject_extint(intack.vector);
- pt_intr_post(v, intack);
+ if (intack.source != hvm_intsrc_vector)
+ pt_intr_post(v, intack);
}
/* Is there another IRQ to queue up behind this one? */
diff -r 12c79a476007 xen/common/kernel.c
--- a/xen/common/kernel.c Tue May 25 09:08:34 2010 +0100
+++ b/xen/common/kernel.c Tue May 25 10:44:07 2010 +0100
@@ -260,7 +260,8 @@
(1U << XENFEAT_highmem_assist) |
(1U << XENFEAT_gnttab_map_avail_bits);
else
- fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
+ fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+ (1U << XENFEAT_hvm_callback_vector);
#endif
break;
default:
diff -r 12c79a476007 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h Tue May 25 09:08:34 2010 +0100
+++ b/xen/include/asm-x86/domain.h Tue May 25 10:44:07 2010 +0100
@@ -18,6 +18,10 @@
#define is_pv_32on64_domain(d) (0)
#endif
#define is_pv_32on64_vcpu(v) (is_pv_32on64_domain((v)->domain))
+
+#define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \
+ d->arch.hvm_domain.irq.callback_via_type == HVMIRQ_callback_vector)
+#define is_hvm_pv_evtchn_vcpu(v) (is_hvm_pv_evtchn_domain(v->domain))
#define VCPU_TRAP_NMI 1
#define VCPU_TRAP_MCE 2
diff -r 12c79a476007 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Tue May 25 09:08:34 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Tue May 25 10:44:07 2010 +0100
@@ -33,7 +33,8 @@
hvm_intsrc_pic,
hvm_intsrc_lapic,
hvm_intsrc_nmi,
- hvm_intsrc_mce
+ hvm_intsrc_mce,
+ hvm_intsrc_vector
};
struct hvm_intack {
uint8_t source; /* enum hvm_intsrc */
@@ -44,6 +45,7 @@
#define hvm_intack_lapic(vec) ( (struct hvm_intack) { hvm_intsrc_lapic, vec } )
#define hvm_intack_nmi ( (struct hvm_intack) { hvm_intsrc_nmi, 2 } )
#define hvm_intack_mce ( (struct hvm_intack) { hvm_intsrc_mce, 18 } )
+#define hvm_intack_vector(vec)( (struct hvm_intack) { hvm_intsrc_vector, vec } )
enum hvm_intblk {
hvm_intblk_none, /* not blocked (deliverable) */
hvm_intblk_shadow, /* MOV-SS or STI shadow */
diff -r 12c79a476007 xen/include/asm-x86/hvm/irq.h
--- a/xen/include/asm-x86/hvm/irq.h Tue May 25 09:08:34 2010 +0100
+++ b/xen/include/asm-x86/hvm/irq.h Tue May 25 10:44:07 2010 +0100
@@ -54,12 +54,14 @@
enum {
HVMIRQ_callback_none,
HVMIRQ_callback_gsi,
- HVMIRQ_callback_pci_intx
+ HVMIRQ_callback_pci_intx,
+ HVMIRQ_callback_vector
} callback_via_type;
};
union {
uint32_t gsi;
struct { uint8_t dev, intx; } pci;
+ uint32_t vector;
} callback_via;
/* Number of INTx wires asserting each PCI-ISA link. */
diff -r 12c79a476007 xen/include/public/features.h
--- a/xen/include/public/features.h Tue May 25 09:08:34 2010 +0100
+++ b/xen/include/public/features.h Tue May 25 10:44:07 2010 +0100
@@ -68,6 +68,9 @@
*/
#define XENFEAT_gnttab_map_avail_bits 7
+/* x86: Does this Xen host support the HVM callback vector type? */
+#define XENFEAT_hvm_callback_vector 8
+
/* x86: pvclock algorithm is safe to use on HVM */
#define XENFEAT_hvm_safe_pvclock 9
diff -r 12c79a476007 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h Tue May 25 09:08:34 2010 +0100
+++ b/xen/include/public/hvm/params.h Tue May 25 10:44:07 2010 +0100
@@ -33,6 +33,9 @@
* val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
* Domain = val[47:32], Bus = val[31:16],
* DevFn = val[15: 8], IntX = val[ 1: 0]
+ * val[63:56] == 2: val[7:0] is a vector number, check for
+ * XENFEAT_hvm_callback_vector to know if this delivery
+ * method is available.
* If val == 0 then CPU0 event-channel notifications are not delivered.
*/
#define HVM_PARAM_CALLBACK_IRQ 0
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-25 9:55 ` Stefano Stabellini
@ 2010-05-26 6:51 ` Boris Derzhavets
2010-05-26 7:31 ` Keir Fraser
0 siblings, 1 reply; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-26 6:51 UTC (permalink / raw)
To: Keir Fraser, Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 8466 bytes --]
Patch bellow contains :-
--- a/xen/common/kernel.c Tue May 25 09:08:34 2010 +0100
+++ b/xen/common/kernel.c Tue May 25 10:44:07 2010 +0100
@@ -260,7 +260,8 @@
(1U << XENFEAT_highmem_assist) |
(1U << XENFEAT_gnttab_map_avail_bits);
else
- fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
+ fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+ (1U << XENFEAT_hvm_callback_vector);
#endif
However, file xen/common/kernel.c under xen-4.0.0 doesn't contain entry
fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
Boris.
--- On Tue, 5/25/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Keir Fraser" <Keir.Fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Tuesday, May 25, 2010, 5:55 AM
On Mon, 24 May 2010, Keir Fraser wrote:
> Please add documentation to include/public/hvm/param.h about how to specify
> the new callback method, and detect when it is available. Move the new
> is_hvm_pv_blah macros out into an appropriate include/asm-x86 header file --
> They are not arch independent.
Done.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
diff -r 12c79a476007 xen/arch/x86/hvm/irq.c
--- a/xen/arch/x86/hvm/irq.c Tue May 25 09:08:34 2010 +0100
+++ b/xen/arch/x86/hvm/irq.c Tue May 25 10:44:07 2010 +0100
@@ -185,16 +185,16 @@
void hvm_assert_evtchn_irq(struct vcpu *v)
{
- if ( v->vcpu_id != 0 )
- return;
-
if ( unlikely(in_irq() || !local_irq_is_enabled()) )
{
tasklet_schedule(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
return;
}
- hvm_set_callback_irq_level(v);
+ if ( is_hvm_pv_evtchn_vcpu(v) )
+ vcpu_kick(v);
+ else if ( v->vcpu_id == 0 )
+ hvm_set_callback_irq_level(v);
}
void hvm_set_pci_link_route(struct domain *d, u8 link, u8 isa_irq)
@@ -251,7 +251,7 @@
via_type = (uint8_t)(via >> 56) + 1;
if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
- (via_type > HVMIRQ_callback_pci_intx) )
+ (via_type > HVMIRQ_callback_vector) )
via_type = HVMIRQ_callback_none;
spin_lock(&d->arch.hvm_domain.irq_lock);
@@ -297,6 +297,9 @@
if ( hvm_irq->callback_via_asserted )
__hvm_pci_intx_assert(d, pdev, pintx);
break;
+ case HVMIRQ_callback_vector:
+ hvm_irq->callback_via.vector = (uint8_t)via;
+ break;
default:
break;
}
@@ -312,6 +315,10 @@
case HVMIRQ_callback_pci_intx:
printk("PCI INTx Dev 0x%02x Int%c\n", pdev, 'A' + pintx);
break;
+ case HVMIRQ_callback_vector:
+ printk("Set HVMIRQ_callback_vector to %u\n",
+ hvm_irq->callback_via.vector);
+ break;
default:
printk("None\n");
break;
@@ -323,6 +330,10 @@
struct hvm_domain *plat = &v->domain->arch.hvm_domain;
int vector;
+ if (plat->irq.callback_via_type == HVMIRQ_callback_vector &&
+ vcpu_info(v, evtchn_upcall_pending))
+ return hvm_intack_vector(plat->irq.callback_via.vector);
+
if ( unlikely(v->nmi_pending) )
return hvm_intack_nmi;
@@ -363,6 +374,8 @@
case hvm_intsrc_lapic:
if ( !vlapic_ack_pending_irq(v, intack.vector) )
intack = hvm_intack_none;
+ break;
+ case hvm_intsrc_vector:
break;
default:
intack = hvm_intack_none;
diff -r 12c79a476007 xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c Tue May 25 09:08:34 2010 +0100
+++ b/xen/arch/x86/hvm/vmx/intr.c Tue May 25 10:44:07 2010 +0100
@@ -164,7 +164,8 @@
{
HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
vmx_inject_extint(intack.vector);
- pt_intr_post(v, intack);
+ if (intack.source != hvm_intsrc_vector)
+ pt_intr_post(v, intack);
}
/* Is there another IRQ to queue up behind this one? */
diff -r 12c79a476007 xen/common/kernel.c
--- a/xen/common/kernel.c Tue May 25 09:08:34 2010 +0100
+++ b/xen/common/kernel.c Tue May 25 10:44:07 2010 +0100
@@ -260,7 +260,8 @@
(1U << XENFEAT_highmem_assist) |
(1U << XENFEAT_gnttab_map_avail_bits);
else
- fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
+ fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+ (1U << XENFEAT_hvm_callback_vector);
#endif
break;
default:
diff -r 12c79a476007 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h Tue May 25 09:08:34 2010 +0100
+++ b/xen/include/asm-x86/domain.h Tue May 25 10:44:07 2010 +0100
@@ -18,6 +18,10 @@
#define is_pv_32on64_domain(d) (0)
#endif
#define is_pv_32on64_vcpu(v) (is_pv_32on64_domain((v)->domain))
+
+#define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \
+ d->arch.hvm_domain.irq.callback_via_type == HVMIRQ_callback_vector)
+#define is_hvm_pv_evtchn_vcpu(v) (is_hvm_pv_evtchn_domain(v->domain))
#define VCPU_TRAP_NMI 1
#define VCPU_TRAP_MCE 2
diff -r 12c79a476007 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Tue May 25 09:08:34 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Tue May 25 10:44:07 2010 +0100
@@ -33,7 +33,8 @@
hvm_intsrc_pic,
hvm_intsrc_lapic,
hvm_intsrc_nmi,
- hvm_intsrc_mce
+ hvm_intsrc_mce,
+ hvm_intsrc_vector
};
struct hvm_intack {
uint8_t source; /* enum hvm_intsrc */
@@ -44,6 +45,7 @@
#define hvm_intack_lapic(vec) ( (struct hvm_intack) { hvm_intsrc_lapic, vec } )
#define hvm_intack_nmi ( (struct hvm_intack) { hvm_intsrc_nmi, 2 } )
#define hvm_intack_mce ( (struct hvm_intack) { hvm_intsrc_mce, 18 } )
+#define hvm_intack_vector(vec)( (struct hvm_intack) { hvm_intsrc_vector, vec } )
enum hvm_intblk {
hvm_intblk_none, /* not blocked (deliverable) */
hvm_intblk_shadow, /* MOV-SS or STI shadow */
diff -r 12c79a476007 xen/include/asm-x86/hvm/irq.h
--- a/xen/include/asm-x86/hvm/irq.h Tue May 25 09:08:34 2010 +0100
+++ b/xen/include/asm-x86/hvm/irq.h Tue May 25 10:44:07 2010 +0100
@@ -54,12 +54,14 @@
enum {
HVMIRQ_callback_none,
HVMIRQ_callback_gsi,
- HVMIRQ_callback_pci_intx
+ HVMIRQ_callback_pci_intx,
+ HVMIRQ_callback_vector
} callback_via_type;
};
union {
uint32_t gsi;
struct { uint8_t dev, intx; } pci;
+ uint32_t vector;
} callback_via;
/* Number of INTx wires asserting each PCI-ISA link. */
diff -r 12c79a476007 xen/include/public/features.h
--- a/xen/include/public/features.h Tue May 25 09:08:34 2010 +0100
+++ b/xen/include/public/features.h Tue May 25 10:44:07 2010 +0100
@@ -68,6 +68,9 @@
*/
#define XENFEAT_gnttab_map_avail_bits 7
+/* x86: Does this Xen host support the HVM callback vector type? */
+#define XENFEAT_hvm_callback_vector 8
+
/* x86: pvclock algorithm is safe to use on HVM */
#define XENFEAT_hvm_safe_pvclock 9
diff -r 12c79a476007 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h Tue May 25 09:08:34 2010 +0100
+++ b/xen/include/public/hvm/params.h Tue May 25 10:44:07 2010 +0100
@@ -33,6 +33,9 @@
* val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
* Domain = val[47:32], Bus = val[31:16],
* DevFn = val[15: 8], IntX = val[ 1: 0]
+ * val[63:56] == 2: val[7:0] is a vector number, check for
+ * XENFEAT_hvm_callback_vector to know if this delivery
+ * method is available.
* If val == 0 then CPU0 event-channel notifications are not delivered.
*/
#define HVM_PARAM_CALLBACK_IRQ 0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 13463 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-26 6:51 ` Boris Derzhavets
@ 2010-05-26 7:31 ` Keir Fraser
2010-05-26 9:58 ` Boris Derzhavets
0 siblings, 1 reply; 25+ messages in thread
From: Keir Fraser @ 2010-05-26 7:31 UTC (permalink / raw)
To: Boris Derzhavets, Stefano Stabellini; +Cc: xen-devel@lists.xensource.com
The patch isn't for 4.0. You can apply it by hand anyway. The missing
hvm_safe_pvclock doesn't matter.
K.
On 26/05/2010 07:51, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote:
> Patch bellow contains :-
>
> --- a/xen/common/kernel.c Tue May 25 09:08:34 2010 +0100
> +++ b/xen/common/kernel.c Tue May 25 10:44:07 2010 +0100
> @@ -260,7 +260,8 @@
> (1U << XENFEAT_highmem_assist) |
> (1U << XENFEAT_gnttab_map_avail_bits);
> else
> - fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
> + fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
> + (1U << XENFEAT_hvm_callback_vector);
> #endif
>
> However, file xen/common/kernel.c under xen-4.0.0 doesn't contain entry
>
> fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
>
> Boris.
>
> --- On Tue, 5/25/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
>>
>> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn
>> delivery
>> To: "Keir Fraser" <Keir.Fraser@eu.citrix.com>
>> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Stefano
>> Stabellini" <Stefano.Stabellini@eu.citrix.com>
>> Date: Tuesday, May 25, 2010, 5:55 AM
>>
>> On Mon, 24 May 2010, Keir Fraser wrote:
>>> Please add documentation to include/public/hvm/param.h about how to specify
>>> the new callback method, and detect when it is available. Move the new
>>> is_hvm_pv_blah macros out into an appropriate include/asm-x86 header file --
>>> They are not arch independent.
>>
>> Done.
>>
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com
>> </mc/compose?to=stefano.stabellini@eu.citrix.com> >
>>
>> ---
>>
>>
>> diff -r 12c79a476007 xen/arch/x86/hvm/irq.c
>> --- a/xen/arch/x86/hvm/irq.c Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/arch/x86/hvm/irq.c Tue May 25 10:44:07 2010 +0100
>> @@ -185,16 +185,16 @@
>>
>> void hvm_assert_evtchn_irq(struct vcpu *v)
>> {
>> - if ( v->vcpu_id != 0 )
>> - return;
>> -
>> if ( unlikely(in_irq() || !local_irq_is_enabled()) )
>> {
>> tasklet_schedule(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
>> return;
>> }
>>
>> - hvm_set_callback_irq_level(v);
>> + if ( is_hvm_pv_evtchn_vcpu(v) )
>> + vcpu_kick(v);
>> + else if ( v->vcpu_id == 0 )
>> + hvm_set_callback_irq_level(v);
>> }
>>
>> void hvm_set_pci_link_route(struct domain *d, u8 link, u8 isa_irq)
>> @@ -251,7 +251,7 @@
>>
>> via_type = (uint8_t)(via >> 56) + 1;
>> if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
>> - (via_type > HVMIRQ_callback_pci_intx) )
>> + (via_type > HVMIRQ_callback_vector) )
>> via_type = HVMIRQ_callback_none;
>>
>> spin_lock(&d->arch.hvm_domain.irq_lock);
>> @@ -297,6 +297,9 @@
>> if ( hvm_irq->callback_via_asserted )
>> __hvm_pci_intx_assert(d, pdev, pintx);
>> break;
>> + case HVMIRQ_callback_vector:
>> + hvm_irq->callback_via.vector = (uint8_t)via;
>> + break;
>> default:
>> break;
>> }
>> @@ -312,6 +315,10 @@
>> case HVMIRQ_callback_pci_intx:
>> printk("PCI INTx Dev 0x%02x Int%c\n", pdev, 'A' + pintx);
>> break;
>> + case HVMIRQ_callback_vector:
>> + printk("Set HVMIRQ_callback_vector to %u\n",
>> + hvm_irq->callback_via.vector);
>> + break;
>> default:
>> printk("None\n");
>> break;
>> @@ -323,6 +330,10 @@
>> struct hvm_domain *plat = &v->domain->arch.hvm_domain;
>> int vector;
>>
>> + if (plat->irq.callback_via_type == HVMIRQ_callback_vector &&
>> + vcpu_info(v, evtchn_upcall_pending))
>> + return hvm_intack_vector(plat->irq.callback_via.vector);
>> +
>> if ( unlikely(v->nmi_pending) )
>> return hvm_intack_nmi;
>>
>> @@ -363,6 +374,8 @@
>> case hvm_intsrc_lapic:
>> if ( !vlapic_ack_pending_irq(v, intack.vector) )
>> intack = hvm_intack_none;
>> + break;
>> + case hvm_intsrc_vector:
>> break;
>> default:
>> intack = hvm_intack_none;
>> diff -r 12c79a476007 xen/arch/x86/hvm/vmx/intr.c
>> --- a/xen/arch/x86/hvm/vmx/intr.c Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/arch/x86/hvm/vmx/intr.c Tue May 25 10:44:07 2010 +0100
>> @@ -164,7 +164,8 @@
>> {
>> HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
>> vmx_inject_extint(intack.vector);
>> - pt_intr_post(v, intack);
>> + if (intack.source != hvm_intsrc_vector)
>> + pt_intr_post(v, intack);
>> }
>>
>> /* Is there another IRQ to queue up behind this one? */
>> diff -r 12c79a476007 xen/common/kernel.c
>> --- a/xen/common/kernel.c Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/common/kernel.c Tue May 25 10:44:07 2010 +0100
>> @@ -260,7 +260,8 @@
>> (1U << XENFEAT_highmem_assist) |
>> (1U << XENFEAT_gnttab_map_avail_bits);
>> else
>> - fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
>> + fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
>> + (1U << XENFEAT_hvm_callback_vector);
>> #endif
>> break;
>> default:
>> diff -r 12c79a476007 xen/include/asm-x86/domain.h
>> --- a/xen/include/asm-x86/domain.h Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/include/asm-x86/domain.h Tue May 25 10:44:07 2010 +0100
>> @@ -18,6 +18,10 @@
>> #define is_pv_32on64_domain(d) (0)
>> #endif
>> #define is_pv_32on64_vcpu(v) (is_pv_32on64_domain((v)->domain))
>> +
>> +#define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \
>> + d->arch.hvm_domain.irq.callback_via_type == HVMIRQ_callback_vector)
>> +#define is_hvm_pv_evtchn_vcpu(v) (is_hvm_pv_evtchn_domain(v->domain))
>>
>> #define VCPU_TRAP_NMI 1
>> #define VCPU_TRAP_MCE 2
>> diff -r 12c79a476007 xen/include/asm-x86/hvm/hvm.h
>> --- a/xen/include/asm-x86/hvm/hvm.h Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/include/asm-x86/hvm/hvm.h Tue May 25 10:44:07 2010 +0100
>> @@ -33,7 +33,8 @@
>> hvm_intsrc_pic,
>> hvm_intsrc_lapic,
>> hvm_intsrc_nmi,
>> - hvm_intsrc_mce
>> + hvm_intsrc_mce,
>> + hvm_intsrc_vector
>> };
>> struct hvm_intack {
>> uint8_t source; /* enum hvm_intsrc */
>> @@ -44,6 +45,7 @@
>> #define hvm_intack_lapic(vec) ( (struct hvm_intack) { hvm_intsrc_lapic, vec
>> } )
>> #define hvm_intack_nmi ( (struct hvm_intack) { hvm_intsrc_nmi, 2 }
>> )
>> #define hvm_intack_mce ( (struct hvm_intack) { hvm_intsrc_mce, 18 }
>> )
>> +#define hvm_intack_vector(vec)( (struct hvm_intack) { hvm_intsrc_vector, vec
>> } )
>> enum hvm_intblk {
>> hvm_intblk_none, /* not blocked (deliverable) */
>> hvm_intblk_shadow, /* MOV-SS or STI shadow */
>> diff -r 12c79a476007 xen/include/asm-x86/hvm/irq.h
>> --- a/xen/include/asm-x86/hvm/irq.h Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/include/asm-x86/hvm/irq.h Tue May 25 10:44:07 2010 +0100
>> @@ -54,12 +54,14 @@
>> enum {
>> HVMIRQ_callback_none,
>> HVMIRQ_callback_gsi,
>> - HVMIRQ_callback_pci_intx
>> + HVMIRQ_callback_pci_intx,
>> + HVMIRQ_callback_vector
>> } callback_via_type;
>> };
>> union {
>> uint32_t gsi;
>> struct { uint8_t dev, intx; } pci;
>> + uint32_t vector;
>> } callback_via;
>>
>> /* Number of INTx wires asserting each PCI-ISA link. */
>> diff -r 12c79a476007 xen/include/public/features.h
>> --- a/xen/include/public/features.h Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/include/public/features.h Tue May 25 10:44:07 2010 +0100
>> @@ -68,6 +68,9 @@
>> */
>> #define XENFEAT_gnttab_map_avail_bits 7
>>
>> +/* x86: Does this Xen host support the HVM callback vector type? */
>> +#define XENFEAT_hvm_callback_vector 8
>> +
>> /* x86: pvclock algorithm is safe to use on HVM */
>> #define XENFEAT_hvm_safe_pvclock 9
>>
>> diff -r 12c79a476007 xen/include/public/hvm/params.h
>> --- a/xen/include/public/hvm/params.h Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/include/public/hvm/params.h Tue May 25 10:44:07 2010 +0100
>> @@ -33,6 +33,9 @@
>> * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
>> * Domain = val[47:32], Bus = val[31:16],
>> * DevFn = val[15: 8], IntX = val[ 1: 0]
>> + * val[63:56] == 2: val[7:0] is a vector number, check for
>> + * XENFEAT_hvm_callback_vector to know if this delivery
>> + * method is available.
>> * If val == 0 then CPU0 event-channel notifications are not delivered.
>> */
>> #define HVM_PARAM_CALLBACK_IRQ 0
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com </mc/compose?to=Xen-devel@lists.xensource.com>
>> http://lists.xensource.com/xen-devel
>
>
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-26 7:31 ` Keir Fraser
@ 2010-05-26 9:58 ` Boris Derzhavets
2010-05-26 11:12 ` Stefano Stabellini
0 siblings, 1 reply; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-26 9:58 UTC (permalink / raw)
To: Stefano Stabellini, Keir Fraser; +Cc: xen-devel@lists.xensource.com
[-- Attachment #1.1: Type: text/plain, Size: 10019 bytes --]
When i run rpmbuild on F13 , i need pv-on-hvm.patch in SOURCES for xen-4.0.0.1.7.f12.src.rpm.
That was a reason of my request yesterday.
Boris.
--- On Wed, 5/26/10, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
From: Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wednesday, May 26, 2010, 3:31 AM
The patch isn't for 4.0. You can apply it by hand anyway. The missing
hvm_safe_pvclock doesn't matter.
K.
On 26/05/2010 07:51, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote:
> Patch bellow contains :-
>
> --- a/xen/common/kernel.c Tue May 25 09:08:34 2010 +0100
> +++ b/xen/common/kernel.c Tue May 25 10:44:07 2010 +0100
> @@ -260,7 +260,8 @@
> (1U << XENFEAT_highmem_assist) |
> (1U << XENFEAT_gnttab_map_avail_bits);
> else
> - fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
> + fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
> + (1U << XENFEAT_hvm_callback_vector);
> #endif
>
> However, file xen/common/kernel.c under xen-4.0.0 doesn't contain entry
>
> fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
>
> Boris.
>
> --- On Tue, 5/25/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
>>
>> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn
>> delivery
>> To: "Keir Fraser" <Keir.Fraser@eu.citrix.com>
>> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Stefano
>> Stabellini" <Stefano.Stabellini@eu.citrix.com>
>> Date: Tuesday, May 25, 2010, 5:55 AM
>>
>> On Mon, 24 May 2010, Keir Fraser wrote:
>>> Please add documentation to include/public/hvm/param.h about how to specify
>>> the new callback method, and detect when it is available. Move the new
>>> is_hvm_pv_blah macros out into an appropriate include/asm-x86 header file --
>>> They are not arch independent.
>>
>> Done.
>>
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com
>> </mc/compose?to=stefano.stabellini@eu.citrix.com> >
>>
>> ---
>>
>>
>> diff -r 12c79a476007 xen/arch/x86/hvm/irq.c
>> --- a/xen/arch/x86/hvm/irq.c Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/arch/x86/hvm/irq.c Tue May 25 10:44:07 2010 +0100
>> @@ -185,16 +185,16 @@
>>
>> void hvm_assert_evtchn_irq(struct vcpu *v)
>> {
>> - if ( v->vcpu_id != 0 )
>> - return;
>> -
>> if ( unlikely(in_irq() || !local_irq_is_enabled()) )
>> {
>> tasklet_schedule(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
>> return;
>> }
>>
>> - hvm_set_callback_irq_level(v);
>> + if ( is_hvm_pv_evtchn_vcpu(v) )
>> + vcpu_kick(v);
>> + else if ( v->vcpu_id == 0 )
>> + hvm_set_callback_irq_level(v);
>> }
>>
>> void hvm_set_pci_link_route(struct domain *d, u8 link, u8 isa_irq)
>> @@ -251,7 +251,7 @@
>>
>> via_type = (uint8_t)(via >> 56) + 1;
>> if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
>> - (via_type > HVMIRQ_callback_pci_intx) )
>> + (via_type > HVMIRQ_callback_vector) )
>> via_type = HVMIRQ_callback_none;
>>
>> spin_lock(&d->arch.hvm_domain.irq_lock);
>> @@ -297,6 +297,9 @@
>> if ( hvm_irq->callback_via_asserted )
>> __hvm_pci_intx_assert(d, pdev, pintx);
>> break;
>> + case HVMIRQ_callback_vector:
>> + hvm_irq->callback_via.vector = (uint8_t)via;
>> + break;
>> default:
>> break;
>> }
>> @@ -312,6 +315,10 @@
>> case HVMIRQ_callback_pci_intx:
>> printk("PCI INTx Dev 0x%02x Int%c\n", pdev, 'A' + pintx);
>> break;
>> + case HVMIRQ_callback_vector:
>> + printk("Set HVMIRQ_callback_vector to %u\n",
>> + hvm_irq->callback_via.vector);
>> + break;
>> default:
>> printk("None\n");
>> break;
>> @@ -323,6 +330,10 @@
>> struct hvm_domain *plat = &v->domain->arch.hvm_domain;
>> int vector;
>>
>> + if (plat->irq.callback_via_type == HVMIRQ_callback_vector &&
>> + vcpu_info(v, evtchn_upcall_pending))
>> + return hvm_intack_vector(plat->irq.callback_via.vector);
>> +
>> if ( unlikely(v->nmi_pending) )
>> return hvm_intack_nmi;
>>
>> @@ -363,6 +374,8 @@
>> case hvm_intsrc_lapic:
>> if ( !vlapic_ack_pending_irq(v, intack.vector) )
>> intack = hvm_intack_none;
>> + break;
>> + case hvm_intsrc_vector:
>> break;
>> default:
>> intack = hvm_intack_none;
>> diff -r 12c79a476007 xen/arch/x86/hvm/vmx/intr.c
>> --- a/xen/arch/x86/hvm/vmx/intr.c Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/arch/x86/hvm/vmx/intr.c Tue May 25 10:44:07 2010 +0100
>> @@ -164,7 +164,8 @@
>> {
>> HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
>> vmx_inject_extint(intack.vector);
>> - pt_intr_post(v, intack);
>> + if (intack.source != hvm_intsrc_vector)
>> + pt_intr_post(v, intack);
>> }
>>
>> /* Is there another IRQ to queue up behind this one? */
>> diff -r 12c79a476007 xen/common/kernel.c
>> --- a/xen/common/kernel.c Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/common/kernel.c Tue May 25 10:44:07 2010 +0100
>> @@ -260,7 +260,8 @@
>> (1U << XENFEAT_highmem_assist) |
>> (1U << XENFEAT_gnttab_map_avail_bits);
>> else
>> - fi.submap |= (1U << XENFEAT_hvm_safe_pvclock);
>> + fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
>> + (1U << XENFEAT_hvm_callback_vector);
>> #endif
>> break;
>> default:
>> diff -r 12c79a476007 xen/include/asm-x86/domain.h
>> --- a/xen/include/asm-x86/domain.h Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/include/asm-x86/domain.h Tue May 25 10:44:07 2010 +0100
>> @@ -18,6 +18,10 @@
>> #define is_pv_32on64_domain(d) (0)
>> #endif
>> #define is_pv_32on64_vcpu(v) (is_pv_32on64_domain((v)->domain))
>> +
>> +#define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \
>> + d->arch.hvm_domain.irq.callback_via_type == HVMIRQ_callback_vector)
>> +#define is_hvm_pv_evtchn_vcpu(v) (is_hvm_pv_evtchn_domain(v->domain))
>>
>> #define VCPU_TRAP_NMI 1
>> #define VCPU_TRAP_MCE 2
>> diff -r 12c79a476007 xen/include/asm-x86/hvm/hvm.h
>> --- a/xen/include/asm-x86/hvm/hvm.h Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/include/asm-x86/hvm/hvm.h Tue May 25 10:44:07 2010 +0100
>> @@ -33,7 +33,8 @@
>> hvm_intsrc_pic,
>> hvm_intsrc_lapic,
>> hvm_intsrc_nmi,
>> - hvm_intsrc_mce
>> + hvm_intsrc_mce,
>> + hvm_intsrc_vector
>> };
>> struct hvm_intack {
>> uint8_t source; /* enum hvm_intsrc */
>> @@ -44,6 +45,7 @@
>> #define hvm_intack_lapic(vec) ( (struct hvm_intack) { hvm_intsrc_lapic, vec
>> } )
>> #define hvm_intack_nmi ( (struct hvm_intack) { hvm_intsrc_nmi, 2 }
>> )
>> #define hvm_intack_mce ( (struct hvm_intack) { hvm_intsrc_mce, 18 }
>> )
>> +#define hvm_intack_vector(vec)( (struct hvm_intack) { hvm_intsrc_vector, vec
>> } )
>> enum hvm_intblk {
>> hvm_intblk_none, /* not blocked (deliverable) */
>> hvm_intblk_shadow, /* MOV-SS or STI shadow */
>> diff -r 12c79a476007 xen/include/asm-x86/hvm/irq.h
>> --- a/xen/include/asm-x86/hvm/irq.h Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/include/asm-x86/hvm/irq.h Tue May 25 10:44:07 2010 +0100
>> @@ -54,12 +54,14 @@
>> enum {
>> HVMIRQ_callback_none,
>> HVMIRQ_callback_gsi,
>> - HVMIRQ_callback_pci_intx
>> + HVMIRQ_callback_pci_intx,
>> + HVMIRQ_callback_vector
>> } callback_via_type;
>> };
>> union {
>> uint32_t gsi;
>> struct { uint8_t dev, intx; } pci;
>> + uint32_t vector;
>> } callback_via;
>>
>> /* Number of INTx wires asserting each PCI-ISA link. */
>> diff -r 12c79a476007 xen/include/public/features.h
>> --- a/xen/include/public/features.h Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/include/public/features.h Tue May 25 10:44:07 2010 +0100
>> @@ -68,6 +68,9 @@
>> */
>> #define XENFEAT_gnttab_map_avail_bits 7
>>
>> +/* x86: Does this Xen host support the HVM callback vector type? */
>> +#define XENFEAT_hvm_callback_vector 8
>> +
>> /* x86: pvclock algorithm is safe to use on HVM */
>> #define XENFEAT_hvm_safe_pvclock 9
>>
>> diff -r 12c79a476007 xen/include/public/hvm/params.h
>> --- a/xen/include/public/hvm/params.h Tue May 25 09:08:34 2010 +0100
>> +++ b/xen/include/public/hvm/params.h Tue May 25 10:44:07 2010 +0100
>> @@ -33,6 +33,9 @@
>> * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
>> * Domain = val[47:32], Bus = val[31:16],
>> * DevFn = val[15: 8], IntX = val[ 1: 0]
>> + * val[63:56] == 2: val[7:0] is a vector number, check for
>> + * XENFEAT_hvm_callback_vector to know if this delivery
>> + * method is available.
>> * If val == 0 then CPU0 event-channel notifications are not delivered.
>> */
>> #define HVM_PARAM_CALLBACK_IRQ 0
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com </mc/compose?to=Xen-devel@lists.xensource.com>
>> http://lists.xensource.com/xen-devel
>
>
[-- Attachment #1.2: Type: text/html, Size: 17053 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-26 9:58 ` Boris Derzhavets
@ 2010-05-26 11:12 ` Stefano Stabellini
2010-05-26 12:02 ` Boris Derzhavets
2010-05-26 12:07 ` Boris Derzhavets
0 siblings, 2 replies; 25+ messages in thread
From: Stefano Stabellini @ 2010-05-26 11:12 UTC (permalink / raw)
To: Boris Derzhavets
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1: Type: text/plain, Size: 258 bytes --]
On Wed, 26 May 2010, Boris Derzhavets wrote:
> When i run rpmbuild on F13 , i need pv-on-hvm.patch in SOURCES for xen-4.0.0.1.7.f12.src.rpm.
> That was a reason of my request yesterday.
>
I am attaching to this email an untested port of the patch to 4.0.
[-- Attachment #2: Type: text/plain, Size: 6659 bytes --]
diff -r e9110e15235c xen/arch/x86/hvm/irq.c
--- a/xen/arch/x86/hvm/irq.c Wed May 26 08:29:15 2010 +0100
+++ b/xen/arch/x86/hvm/irq.c Wed May 26 12:12:36 2010 +0100
@@ -185,16 +185,16 @@
void hvm_assert_evtchn_irq(struct vcpu *v)
{
- if ( v->vcpu_id != 0 )
- return;
-
if ( unlikely(in_irq() || !local_irq_is_enabled()) )
{
tasklet_schedule(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
return;
}
- hvm_set_callback_irq_level(v);
+ if ( is_hvm_pv_evtchn_vcpu(v) )
+ vcpu_kick(v);
+ else if ( v->vcpu_id == 0 )
+ hvm_set_callback_irq_level(v);
}
void hvm_set_pci_link_route(struct domain *d, u8 link, u8 isa_irq)
@@ -251,7 +251,7 @@
via_type = (uint8_t)(via >> 56) + 1;
if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
- (via_type > HVMIRQ_callback_pci_intx) )
+ (via_type > HVMIRQ_callback_vector) )
via_type = HVMIRQ_callback_none;
spin_lock(&d->arch.hvm_domain.irq_lock);
@@ -297,6 +297,9 @@
if ( hvm_irq->callback_via_asserted )
__hvm_pci_intx_assert(d, pdev, pintx);
break;
+ case HVMIRQ_callback_vector:
+ hvm_irq->callback_via.vector = (uint8_t)via;
+ break;
default:
break;
}
@@ -312,6 +315,10 @@
case HVMIRQ_callback_pci_intx:
printk("PCI INTx Dev 0x%02x Int%c\n", pdev, 'A' + pintx);
break;
+ case HVMIRQ_callback_vector:
+ printk("Set HVMIRQ_callback_vector to %u\n",
+ hvm_irq->callback_via.vector);
+ break;
default:
printk("None\n");
break;
@@ -323,6 +330,10 @@
struct hvm_domain *plat = &v->domain->arch.hvm_domain;
int vector;
+ if (plat->irq.callback_via_type == HVMIRQ_callback_vector &&
+ vcpu_info(v, evtchn_upcall_pending))
+ return hvm_intack_vector(plat->irq.callback_via.vector);
+
if ( unlikely(v->nmi_pending) )
return hvm_intack_nmi;
@@ -363,6 +374,8 @@
case hvm_intsrc_lapic:
if ( !vlapic_ack_pending_irq(v, intack.vector) )
intack = hvm_intack_none;
+ break;
+ case hvm_intsrc_vector:
break;
default:
intack = hvm_intack_none;
diff -r e9110e15235c xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c Wed May 26 08:29:15 2010 +0100
+++ b/xen/arch/x86/hvm/vmx/intr.c Wed May 26 12:12:36 2010 +0100
@@ -164,7 +164,8 @@
{
HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
vmx_inject_extint(intack.vector);
- pt_intr_post(v, intack);
+ if (intack.source != hvm_intsrc_vector)
+ pt_intr_post(v, intack);
}
/* Is there another IRQ to queue up behind this one? */
diff -r e9110e15235c xen/common/kernel.c
--- a/xen/common/kernel.c Wed May 26 08:29:15 2010 +0100
+++ b/xen/common/kernel.c Wed May 26 12:12:36 2010 +0100
@@ -243,6 +243,8 @@
fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
(1U << XENFEAT_highmem_assist) |
(1U << XENFEAT_gnttab_map_avail_bits);
+ else
+ fi.submap |= (1U << XENFEAT_hvm_callback_vector);
#endif
break;
default:
diff -r e9110e15235c xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h Wed May 26 08:29:15 2010 +0100
+++ b/xen/include/asm-x86/domain.h Wed May 26 12:12:36 2010 +0100
@@ -17,6 +17,10 @@
#define is_pv_32on64_domain(d) (0)
#endif
#define is_pv_32on64_vcpu(v) (is_pv_32on64_domain((v)->domain))
+
+#define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \
+ d->arch.hvm_domain.irq.callback_via_type == HVMIRQ_callback_vector)
+#define is_hvm_pv_evtchn_vcpu(v) (is_hvm_pv_evtchn_domain(v->domain))
#define VCPU_TRAP_NMI 1
#define VCPU_TRAP_MCE 2
diff -r e9110e15235c xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed May 26 08:29:15 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Wed May 26 12:12:36 2010 +0100
@@ -33,7 +33,8 @@
hvm_intsrc_pic,
hvm_intsrc_lapic,
hvm_intsrc_nmi,
- hvm_intsrc_mce
+ hvm_intsrc_mce,
+ hvm_intsrc_vector
};
struct hvm_intack {
uint8_t source; /* enum hvm_intsrc */
@@ -44,6 +45,7 @@
#define hvm_intack_lapic(vec) ( (struct hvm_intack) { hvm_intsrc_lapic, vec } )
#define hvm_intack_nmi ( (struct hvm_intack) { hvm_intsrc_nmi, 2 } )
#define hvm_intack_mce ( (struct hvm_intack) { hvm_intsrc_mce, 18 } )
+#define hvm_intack_vector(vec)( (struct hvm_intack) { hvm_intsrc_vector, vec } )
enum hvm_intblk {
hvm_intblk_none, /* not blocked (deliverable) */
hvm_intblk_shadow, /* MOV-SS or STI shadow */
diff -r e9110e15235c xen/include/asm-x86/hvm/irq.h
--- a/xen/include/asm-x86/hvm/irq.h Wed May 26 08:29:15 2010 +0100
+++ b/xen/include/asm-x86/hvm/irq.h Wed May 26 12:12:36 2010 +0100
@@ -54,12 +54,14 @@
enum {
HVMIRQ_callback_none,
HVMIRQ_callback_gsi,
- HVMIRQ_callback_pci_intx
+ HVMIRQ_callback_pci_intx,
+ HVMIRQ_callback_vector
} callback_via_type;
};
union {
uint32_t gsi;
struct { uint8_t dev, intx; } pci;
+ uint32_t vector;
} callback_via;
/* Number of INTx wires asserting each PCI-ISA link. */
diff -r e9110e15235c xen/include/public/features.h
--- a/xen/include/public/features.h Wed May 26 08:29:15 2010 +0100
+++ b/xen/include/public/features.h Wed May 26 12:12:36 2010 +0100
@@ -68,6 +68,9 @@
*/
#define XENFEAT_gnttab_map_avail_bits 7
+/* x86: Does this Xen host support the HVM callback vector type? */
+#define XENFEAT_hvm_callback_vector 8
+
#define XENFEAT_NR_SUBMAPS 1
#endif /* __XEN_PUBLIC_FEATURES_H__ */
diff -r e9110e15235c xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h Wed May 26 08:29:15 2010 +0100
+++ b/xen/include/public/hvm/params.h Wed May 26 12:12:36 2010 +0100
@@ -33,6 +33,9 @@
* val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
* Domain = val[47:32], Bus = val[31:16],
* DevFn = val[15: 8], IntX = val[ 1: 0]
+ * val[63:56] == 2: val[7:0] is a vector number, check for
+ * XENFEAT_hvm_callback_vector to know if this delivery
+ * method is available.
* If val == 0 then CPU0 event-channel notifications are not delivered.
*/
#define HVM_PARAM_CALLBACK_IRQ 0
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-26 11:12 ` Stefano Stabellini
@ 2010-05-26 12:02 ` Boris Derzhavets
2010-05-26 12:07 ` Boris Derzhavets
1 sibling, 0 replies; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-26 12:02 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 1751 bytes --]
Per Keir's advice i removed hank
diff -r e9110e15235c xen/common/kernel.c
--- a/xen/common/kernel.c Wed May 26 08:29:15 2010 +0100
+++ b/xen/common/kernel.c Wed May 26 12:12:36 2010 +0100
@@ -243,6 +243,8 @@
fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
(1U << XENFEAT_highmem_assist) |
(1U << XENFEAT_gnttab_map_avail_bits);
+ else
+ fi.submap |= (1U << XENFEAT_hvm_callback_vector);
#endif
break;
default:
Applied patch at rpmbuild run, rebuilt xen rpms , made hot hypervisor upgrade
and reboot Xen Instance.
Now building F13 HVM to continue with test PV on HVM following yours the
the most recent submission.
Boris.
--- On Wed, 5/26/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Wednesday, May 26, 2010, 7:12 AM
On Wed, 26 May 2010, Boris Derzhavets wrote:
> When i run rpmbuild on F13 , i need pv-on-hvm.patch in SOURCES for xen-4.0.0.1.7.f12.src.rpm.
> That was a reason of my request yesterday.
>
I am attaching to this email an untested port of the patch to 4.0.
-----Inline Attachment Follows-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 3022 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-26 11:12 ` Stefano Stabellini
2010-05-26 12:02 ` Boris Derzhavets
@ 2010-05-26 12:07 ` Boris Derzhavets
1 sibling, 0 replies; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-26 12:07 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 1033 bytes --]
Sorry, i shouldn't remove hank. It's OK in the most recent submission.
Will upgrade one more time.
Boris.
--- On Wed, 5/26/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Wednesday, May 26, 2010, 7:12 AM
On Wed, 26 May 2010, Boris Derzhavets wrote:
> When i run rpmbuild on F13 , i need pv-on-hvm.patch in SOURCES for xen-4.0.0.1.7.f12.src.rpm.
> That was a reason of my request yesterday.
>
I am attaching to this email an untested port of the patch to 4.0.
-----Inline Attachment Follows-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 1634 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] xen: implement vector callback for evtchn delivery
@ 2010-05-28 16:46 Boris Derzhavets
2010-05-28 16:55 ` Stefano Stabellini
0 siblings, 1 reply; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-28 16:46 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 2583 bytes --]
I redefined DomU via profile :-
<domain type='xen' >
<name>LucidHVM</name>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>2</vcpu>
<os>
<type>hvm</type>
<loader>/usr/lib/xen/boot/hvmloader</loader>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
<disk type='block' device='disk'>
<driver name='phy'/>
<source dev='/dev/sda7'/>
<target dev='xvda' bus='xen'/> - instead of 'ide'
</disk>
<interface type='bridge'>
<mac address='00:16:36:2a:cd:af'/>
<source bridge='br0'/>
<script path='/etc/xen/scripts/vif-bridge'/>
<target dev='vif1.0'/>
</interface>
<serial type='pty'>
<source path='/dev/pts/0'/>
<target port='0'/>
</serial>
<console type='pty' tty='/dev/pts/0'>
<source path='/dev/pts/0'/>
<target port='0'/>
</console>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='5900' autoport='yes' keymap='en-us'/>
<sound model='es1370'/>
</devices>
</domain>
dmesg.log is attached.
Boris.
--- On Fri, 5/28/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Friday, May 28, 2010, 11:59 AM
On Thu, 27 May 2010, Boris Derzhavets wrote:
> <disk type="block" device="disk">
> <driver name="phy"/>
> <source dev="/dev/sda7"/>
> <target dev="hda" bus="ide"/>
> </disk>
> <disk type="file" device="cdrom">
> <target dev="hdc" bus="ide"/>
> <readonly/>
I am pretty sure that the interrupts on the ata_piix device are due to
the cdrom that has been used through the emulated interface.
Using xend/xl, it is possible to make sure your guest can use the pv
interface for the cdrom too, specifying xvdc instead of hdc as virtual
device:
disk = [ 'file:/path/to/iso,xvdc:cdrom,r' ]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 4262 bytes --]
[-- Attachment #2: dmesg2.log.gz --]
[-- Type: application/x-gzip, Size: 7836 bytes --]
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-28 16:46 Boris Derzhavets
@ 2010-05-28 16:55 ` Stefano Stabellini
2010-05-28 17:13 ` Boris Derzhavets
0 siblings, 1 reply; 25+ messages in thread
From: Stefano Stabellini @ 2010-05-28 16:55 UTC (permalink / raw)
To: Boris Derzhavets
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]
On Fri, 28 May 2010, Boris Derzhavets wrote:
> I redefined DomU via profile :-
>
> <domain type='xen' >
> <name>LucidHVM</name>
> <memory>2097152</memory>
> <currentMemory>2097152</currentMemory>
> <vcpu>2</vcpu>
> <os>
> <type>hvm</type>
> <loader>/usr/lib/xen/boot/hvmloader</loader>
> <boot dev='hd'/>
> </os>
> <features>
> <acpi/>
> <apic/>
> <pae/>
> </features>
> <clock offset='utc'/>
> <on_poweroff>destroy</on_poweroff>
> <on_reboot>restart</on_reboot>
> <on_crash>restart</on_crash>
> <devices>
> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
> <disk type='block' device='disk'>
> <driver name='phy'/>
> <source dev='/dev/sda7'/>
> <target dev='xvda' bus='xen'/> - instead of 'ide'
> </disk>
> <interface type='bridge'>
> <mac address='00:16:36:2a:cd:af'/>
> <source bridge='br0'/>
> <script path='/etc/xen/scripts/vif-bridge'/>
> <target dev='vif1.0'/>
> </interface>
> <serial type='pty'>
> <source path='/dev/pts/0'/>
> <target port='0'/>
> </serial>
> <console type='pty' tty='/dev/pts/0'>
> <source path='/dev/pts/0'/>
> <target port='0'/>
> </console>
> <input type='mouse' bus='ps2'/>
> <graphics type='vnc' port='5900' autoport='yes' keymap='en-us'/>
> <sound model='es1370'/>
> </devices>
> </domain>
>
> dmesg.log is attached.
>
I think it should be OK now
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-28 16:55 ` Stefano Stabellini
@ 2010-05-28 17:13 ` Boris Derzhavets
2010-05-28 17:21 ` Stefano Stabellini
0 siblings, 1 reply; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-28 17:13 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 3846 bytes --]
It stays the same as well as dmesg log been sent.
root@LucidSRV:~# cat /proc/interrupts
CPU0 CPU1
0: 30 0 IO-APIC-edge timer
1: 29 102 IO-APIC-edge i8042
4: 1 0 IO-APIC-edge
6: 2 0 IO-APIC-edge floppy
8: 0 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
12: 325 7 IO-APIC-edge i8042
14: 0 0 IO-APIC-edge ata_piix
15: 0 0 IO-APIC-edge ata_piix
16: 196 0 xen-dyn-event xenbus
17: 5057 0 xen-dyn-event blkif
18: 109 0 xen-dyn-event eth0
23: 0 0 IO-APIC-fasteoi uhci_hcd:usb1
36: 0 0 IO-APIC-fasteoi Ensoniq AudioPCI
NMI: 0 0 Non-maskable interrupts
LOC: 2712 2532 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
PND: 0 0 Performance pending work
PLT: 5139 0 Platform interrupts
RES: 1451 1562 Rescheduling interrupts
CAL: 117 103 Function call interrupts
TLB: 222 185 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 1 1 Machine check polls
ERR: 0
MIS: 0
Is it OK ?
Boris.
--- On Fri, 5/28/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Friday, May 28, 2010, 12:55 PM
On Fri, 28 May 2010, Boris Derzhavets wrote:
> I redefined DomU via profile :-
>
> <domain type='xen' >
> <name>LucidHVM</name>
> <memory>2097152</memory>
> <currentMemory>2097152</currentMemory>
> <vcpu>2</vcpu>
> <os>
> <type>hvm</type>
> <loader>/usr/lib/xen/boot/hvmloader</loader>
> <boot dev='hd'/>
> </os>
> <features>
> <acpi/>
> <apic/>
> <pae/>
> </features>
> <clock offset='utc'/>
> <on_poweroff>destroy</on_poweroff>
> <on_reboot>restart</on_reboot>
> <on_crash>restart</on_crash>
> <devices>
> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
> <disk type='block' device='disk'>
> <driver name='phy'/>
> <source dev='/dev/sda7'/>
> <target dev='xvda' bus='xen'/> - instead of 'ide'
> </disk>
> <interface type='bridge'>
> <mac address='00:16:36:2a:cd:af'/>
> <source bridge='br0'/>
> <script path='/etc/xen/scripts/vif-bridge'/>
> <target dev='vif1.0'/>
> </interface>
> <serial type='pty'>
> <source path='/dev/pts/0'/>
> <target port='0'/>
> </serial>
> <console type='pty' tty='/dev/pts/0'>
> <source path='/dev/pts/0'/>
> <target port='0'/>
> </console>
> <input type='mouse' bus='ps2'/>
> <graphics type='vnc' port='5900' autoport='yes' keymap='en-us'/>
> <sound model='es1370'/>
> </devices>
> </domain>
>
> dmesg.log is attached.
>
I think it should be OK now
-----Inline Attachment Follows-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 8772 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-28 17:13 ` Boris Derzhavets
@ 2010-05-28 17:21 ` Stefano Stabellini
2010-05-28 17:19 ` Boris Derzhavets
0 siblings, 1 reply; 25+ messages in thread
From: Stefano Stabellini @ 2010-05-28 17:21 UTC (permalink / raw)
To: Boris Derzhavets
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]
On Fri, 28 May 2010, Boris Derzhavets wrote:
> It stays the same as well as dmesg log been sent.
>
> root@LucidSRV:~# cat /proc/interrupts
> CPU0 CPU1
> 0: 30 0 IO-APIC-edge timer
> 1: 29 102 IO-APIC-edge i8042
> 4: 1 0 IO-APIC-edge
> 6: 2 0 IO-APIC-edge floppy
> 8: 0 0 IO-APIC-edge rtc0
> 9: 0 0 IO-APIC-fasteoi acpi
> 12: 325 7 IO-APIC-edge i8042
> 14: 0 0 IO-APIC-edge ata_piix
> 15: 0 0 IO-APIC-edge ata_piix
> 16: 196 0 xen-dyn-event xenbus
> 17: 5057 0 xen-dyn-event blkif
> 18: 109 0 xen-dyn-event eth0
> 23: 0 0 IO-APIC-fasteoi uhci_hcd:usb1
> 36: 0 0 IO-APIC-fasteoi Ensoniq AudioPCI
> NMI: 0 0 Non-maskable interrupts
> LOC: 2712 2532 Local timer interrupts
> SPU: 0 0 Spurious interrupts
> PMI: 0 0 Performance monitoring interrupts
> PND: 0 0 Performance pending work
> PLT: 5139 0 Platform interrupts
> RES: 1451 1562 Rescheduling interrupts
> CAL: 117 103 Function call interrupts
> TLB: 222 185 TLB shootdowns
> TRM: 0 0 Thermal event interrupts
> THR: 0 0 Threshold APIC interrupts
> MCE: 0 0 Machine check exceptions
> MCP: 1 1 Machine check polls
> ERR: 0
> MIS: 0
>
>
> Is it OK ?
Yep, no more interrupts for your ata_piix devices
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-28 17:21 ` Stefano Stabellini
@ 2010-05-28 17:19 ` Boris Derzhavets
0 siblings, 0 replies; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-28 17:19 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 2518 bytes --]
Got it.
Thank you.
--- On Fri, 5/28/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Friday, May 28, 2010, 1:21 PM
On Fri, 28 May 2010, Boris Derzhavets wrote:
> It stays the same as well as dmesg log been sent.
>
> root@LucidSRV:~# cat /proc/interrupts
> CPU0 CPU1
> 0: 30 0 IO-APIC-edge timer
> 1: 29 102 IO-APIC-edge i8042
> 4: 1 0 IO-APIC-edge
> 6: 2 0 IO-APIC-edge floppy
> 8: 0 0 IO-APIC-edge rtc0
> 9: 0 0 IO-APIC-fasteoi acpi
> 12: 325 7 IO-APIC-edge i8042
> 14: 0 0 IO-APIC-edge ata_piix
> 15: 0 0 IO-APIC-edge ata_piix
> 16: 196 0 xen-dyn-event xenbus
> 17: 5057 0 xen-dyn-event blkif
> 18: 109 0 xen-dyn-event eth0
> 23: 0 0 IO-APIC-fasteoi uhci_hcd:usb1
> 36: 0 0 IO-APIC-fasteoi Ensoniq AudioPCI
> NMI: 0 0 Non-maskable interrupts
> LOC: 2712 2532 Local timer interrupts
> SPU: 0 0 Spurious interrupts
> PMI: 0 0 Performance monitoring interrupts
> PND: 0 0 Performance pending work
> PLT: 5139 0 Platform interrupts
> RES: 1451 1562 Rescheduling interrupts
> CAL: 117 103 Function call interrupts
> TLB: 222 185 TLB shootdowns
> TRM: 0 0 Thermal event interrupts
> THR: 0 0 Threshold APIC interrupts
> MCE: 0 0 Machine check exceptions
> MCP: 1 1 Machine check polls
> ERR: 0
> MIS: 0
>
>
> Is it OK ?
Yep, no more interrupts for your ata_piix devices
-----Inline Attachment Follows-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 6327 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] xen: implement vector callback for evtchn delivery
@ 2010-05-27 8:57 Boris Derzhavets
2010-05-27 12:06 ` Stefano Stabellini
0 siblings, 1 reply; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-27 8:57 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 9014 bytes --]
Seems to done right. Dmesg log for PV on HVM (Ubuntu Lucid) :-
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.34 (root@LucidSRV) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #2 SMP Thu May 27 09:56:26 MSD 2010
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.34 root=UUID=8ab02f1a-d6bd-4829-9732-20440acf320f ro console=tty0
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 0000000080000000 (usable)
[ 0.000000] BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] DMI 2.4 present.
[ 0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
[ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[ 0.000000] No AGP bridge found
[ 0.000000] last_pfn = 0x80000 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: write-back
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF write-combining
[ 0.000000] C0000-FFFFF write-back
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 0F0000000 mask FF8000000 uncachable
[ 0.000000] 1 base 0F8000000 mask FFC000000 uncachable
[ 0.000000] 2 disabled
[ 0.000000] 3 disabled
[ 0.000000] 4 disabled
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] e820 update range: 0000000000001000 - 0000000000010000 (usable) ==> (reserved)
[ 0.000000] Scanning 1 areas for low memory corruption
[ 0.000000] modified physical RAM map:
[ 0.000000] modified: 0000000000000000 - 0000000000010000 (reserved)
[ 0.000000] modified: 0000000000010000 - 000000000009fc00 (usable)
[ 0.000000] modified: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] modified: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] modified: 0000000000100000 - 0000000080000000 (usable)
[ 0.000000] modified: 00000000fc000000 - 0000000100000000 (reserved)
[ 0.000000] initial memory mapped : 0 - 20000000
[ 0.000000] found SMP MP-table at [ffff8800000fbc60] fbc60
[ 0.000000] init_memory_mapping: 0000000000000000-0000000080000000
[ 0.000000] 0000000000 - 0080000000 page 2M
[ 0.000000] kernel direct mapping tables up to 80000000 @ 16000-19000
[ 0.000000] RAMDISK: 33f01000 - 37ff0000
[ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen)
[ 0.000000] ACPI: XSDT 00000000fc012cb0 00034 (v01 Xen HVM 00000000 HVML 00000000)
[ 0.000000] ACPI: FACP 00000000fc012ad0 000F4 (v04 Xen HVM 00000000 HVML 00000000)
[ 0.000000] ACPI: DSDT 00000000fc002c40 0FE0B (v02 Xen HVM 00000000 INTL 20090123)
[ 0.000000] ACPI: FACS 00000000fc002c00 00040
[ 0.000000] ACPI: APIC 00000000fc012bd0 000D8 (v02 Xen HVM 00000000 HVML 00000000)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] No NUMA configuration found
[ 0.000000] Faking a node at 0000000000000000-0000000080000000
[ 0.000000] Initmem setup node 0 0000000000000000-0000000080000000
[ 0.000000] NODE_DATA [0000000001cb20c0 - 0000000001cb70bf]
[ 0.000000] [ffffea0000000000-ffffea0001bfffff] PMD -> [ffff880002600000-ffff8800041fffff] on node 0
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000010 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal empty
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[2] active PFN ranges
[ 0.000000] 0: 0x00000010 -> 0x0000009f
[ 0.000000] 0: 0x00000100 -> 0x00080000
[ 0.000000] On node 0 totalpages: 524175
[ 0.000000] DMA zone: 56 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 3927 pages, LIFO batch:0
[ 0.000000] DMA32 zone: 7112 pages used for memmap
[ 0.000000] DMA32 zone: 513080 pages, LIFO batch:31
[ 0.000000] ACPI: PM-Timer IO Port: 0x1f48
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ5 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] ACPI: IRQ10 used by override.
[ 0.000000] ACPI: IRQ11 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] SMP: Allowing 15 CPUs, 13 hotplug CPUs
[ 0.000000] nr_irqs_gsi: 48
[ 0.000000] Xen version 4.0.
=>[ 0.000000] Xen Platform PCI: I/O protocol version 1
=>[ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
=> [ 0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
=>[ 0.000000] You might have to change the root device
=>[ 0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[ 0.000000] in your root= kernel command line option
[ 0.000000] Xen doesn't support pvclock on HVM,disable pv timer
[ 0.000000] early_res array is doubled to 64 at [17180 - 1797f]
....
"df -h" reports /dev/xvda(X) devices
Boris
--- On Thu, 5/27/10, Boris Derzhavets <bderzhavets@yahoo.com> wrote:
From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Thursday, May 27, 2010, 2:51 AM
Xen 4.0 updated with yours patch on top of F13. Ubuntu Lucid HVM created.
Kernel 2.6.34 been built on HVM per yours the most recent instructions.
HVM reloaded with 2.6.34 kernel. Obvious network performance improvement.
Disk I/O doesn't look much better.
Boris.
--- On Wed, 5/26/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini"
<Stefano.Stabellini@eu.citrix.com>
Date: Wednesday, May 26, 2010, 7:12 AM
On Wed, 26 May 2010, Boris Derzhavets wrote:
> When i run rpmbuild on F13 , i need pv-on-hvm.patch in SOURCES for xen-4.0.0.1.7.f12.src.rpm.
> That was a reason of my request yesterday.
>
I am attaching to this email an untested port of the patch to 4.0.
-----Inline Attachment Follows-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
-----Inline Attachment Follows-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 12617 bytes --]
[-- Attachment #2: dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 8070 bytes --]
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-27 8:57 Boris Derzhavets
@ 2010-05-27 12:06 ` Stefano Stabellini
2010-05-27 13:06 ` Boris Derzhavets
0 siblings, 1 reply; 25+ messages in thread
From: Stefano Stabellini @ 2010-05-27 12:06 UTC (permalink / raw)
To: Boris Derzhavets
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1: Type: text/plain, Size: 7610 bytes --]
On Thu, 27 May 2010, Boris Derzhavets wrote:
> Seems to done right. Dmesg log for PV on HVM (Ubuntu Lucid) :-
>
> [ 0.000000] Initializing cgroup subsys cpuset
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Linux version 2.6.34 (root@LucidSRV) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #2 SMP Thu May 27
> 09:56:26 MSD 2010
> [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.34 root=UUID=8ab02f1a-d6bd-4829-9732-20440acf320f ro
> console=tty0
> [ 0.000000] BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> [ 0.000000] BIOS-e820: 0000000000100000 - 0000000080000000 (usable)
> [ 0.000000] BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] DMI 2.4 present.
> [ 0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
> [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> [ 0.000000] No AGP bridge found
> [ 0.000000] last_pfn = 0x80000 max_arch_pfn = 0x400000000
> [ 0.000000] MTRR default type: write-back
> [ 0.000000] MTRR fixed ranges enabled:
> [ 0.000000] 00000-9FFFF write-back
> [ 0.000000] A0000-BFFFF write-combining
> [ 0.000000] C0000-FFFFF write-back
> [ 0.000000] MTRR variable ranges enabled:
> [ 0.000000] 0 base 0F0000000 mask FF8000000 uncachable
> [ 0.000000] 1 base 0F8000000 mask FFC000000 uncachable
> [ 0.000000] 2 disabled
> [ 0.000000] 3 disabled
> [ 0.000000] 4 disabled
> [ 0.000000] 5 disabled
> [ 0.000000] 6 disabled
> [ 0.000000] 7 disabled
> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> [ 0.000000] e820 update range: 0000000000001000 - 0000000000010000 (usable) ==> (reserved)
> [ 0.000000] Scanning 1 areas for low memory corruption
> [ 0.000000] modified physical RAM map:
> [ 0.000000] modified: 0000000000000000 - 0000000000010000 (reserved)
> [ 0.000000] modified: 0000000000010000 - 000000000009fc00 (usable)
> [ 0.000000] modified: 000000000009fc00 - 00000000000a0000 (reserved)
> [ 0.000000] modified: 00000000000e0000 - 0000000000100000 (reserved)
> [ 0.000000] modified: 0000000000100000 - 0000000080000000 (usable)
> [ 0.000000] modified: 00000000fc000000 - 0000000100000000 (reserved)
> [ 0.000000] initial memory mapped : 0 - 20000000
> [ 0.000000] found SMP MP-table at [ffff8800000fbc60] fbc60
> [ 0.000000] init_memory_mapping: 0000000000000000-0000000080000000
> [ 0.000000] 0000000000 - 0080000000 page 2M
> [ 0.000000] kernel direct mapping tables up to 80000000 @ 16000-19000
> [ 0.000000] RAMDISK: 33f01000 - 37ff0000
> [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen)
> [ 0.000000] ACPI: XSDT 00000000fc012cb0 00034 (v01 Xen HVM 00000000 HVML 00000000)
> [ 0.000000] ACPI: FACP 00000000fc012ad0 000F4 (v04 Xen HVM 00000000 HVML 00000000)
> [ 0.000000] ACPI: DSDT 00000000fc002c40 0FE0B (v02 Xen HVM 00000000 INTL 20090123)
> [ 0.000000] ACPI: FACS 00000000fc002c00 00040
> [ 0.000000] ACPI: APIC 00000000fc012bd0 000D8 (v02 Xen HVM 00000000 HVML 00000000)
> [ 0.000000] ACPI: Local APIC address 0xfee00000
> [ 0.000000] No NUMA configuration found
> [ 0.000000] Faking a node at 0000000000000000-0000000080000000
> [ 0.000000] Initmem setup node 0 0000000000000000-0000000080000000
> [ 0.000000] NODE_DATA [0000000001cb20c0 - 0000000001cb70bf]
> [ 0.000000] [ffffea0000000000-ffffea0001bfffff] PMD -> [ffff880002600000-ffff8800041fffff] on node 0
> [ 0.000000] Zone PFN ranges:
> [ 0.000000] DMA 0x00000010 -> 0x00001000
> [ 0.000000] DMA32 0x00001000 -> 0x00100000
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start PFN for each node
> [ 0.000000] early_node_map[2] active PFN ranges
> [ 0.000000] 0: 0x00000010 -> 0x0000009f
> [ 0.000000] 0: 0x00000100 -> 0x00080000
> [ 0.000000] On node 0 totalpages: 524175
> [ 0.000000] DMA zone: 56 pages used for memmap
> [ 0.000000] DMA zone: 0 pages reserved
> [ 0.000000] DMA zone: 3927 pages, LIFO batch:0
> [ 0.000000] DMA32 zone: 7112 pages used for memmap
> [ 0.000000] DMA32 zone: 513080 pages, LIFO batch:31
> [ 0.000000] ACPI: PM-Timer IO Port: 0x1f48
> [ 0.000000] ACPI: Local APIC address 0xfee00000
> [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
> [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
> [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
> [ 0.000000] ACPI: IRQ0 used by override.
> [ 0.000000] ACPI: IRQ2 used by override.
> [ 0.000000] ACPI: IRQ5 used by override.
> [ 0.000000] ACPI: IRQ9 used by override.
> [ 0.000000] ACPI: IRQ10 used by override.
> [ 0.000000] ACPI: IRQ11 used by override.
> [ 0.000000] Using ACPI (MADT) for SMP configuration information
> [ 0.000000] SMP: Allowing 15 CPUs, 13 hotplug CPUs
> [ 0.000000] nr_irqs_gsi: 48
> [ 0.000000] Xen version 4.0.
> =>[ 0.000000] Xen Platform PCI: I/O protocol version 1
> =>[ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
> => [ 0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
> =>[ 0.000000] You might have to change the root device
> =>[ 0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
> [ 0.000000] in your root= kernel command line option
> [ 0.000000] Xen doesn't support pvclock on HVM,disable pv timer
> [ 0.000000] early_res array is doubled to 64 at [17180 - 1797f]
> ....
>
> "df -h" reports /dev/xvda(X) devices
>
>
everything seems fine, the callback mechanism seems to be working too
(even though I am not writing an explicit message about it, maybe I
should). Please post the output of 'cat /proc/interrupts' just to be
sure...
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-27 12:06 ` Stefano Stabellini
@ 2010-05-27 13:06 ` Boris Derzhavets
2010-05-27 14:58 ` Stefano Stabellini
0 siblings, 1 reply; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-27 13:06 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 9937 bytes --]
root@LucidSRV:~# cat /proc/interrupts
CPU0 CPU1
0: 29 0 IO-APIC-edge timer
1: 107 0 IO-APIC-edge i8042
4: 1 0 IO-APIC-edge
6: 2 0 IO-APIC-edge floppy
8: 0 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
12: 187 496 IO-APIC-edge i8042
14: 0 0 IO-APIC-edge ata_piix
15: 933 0 IO-APIC-edge ata_piix
16: 293 0 xen-dyn-event xenbus
17: 5059 0 xen-dyn-event blkif
18: 0 0 xen-dyn-event blkif
19: 72 0 xen-dyn-event eth0
23: 0 0 IO-APIC-fasteoi uhci_hcd:usb1
36: 0 0 IO-APIC-fasteoi Ensoniq AudioPCI
NMI: 0 0 Non-maskable interrupts
LOC: 2767 2901 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
PND: 0 0 Performance pending work
PLT: 5211 0 Platform interrupts
RES: 1189 1949 Rescheduling interrupts
CAL: 130 89 Function call interrupts
TLB: 230 179 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 1 1 Machine check polls
ERR: 0
MIS: 0
Boris.
--- On Thu, 5/27/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Thursday, May 27, 2010, 8:06 AM
On Thu, 27 May 2010, Boris Derzhavets wrote:
> Seems to done right. Dmesg log for PV on HVM (Ubuntu Lucid) :-
>
> [ 0.000000] Initializing cgroup subsys cpuset
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Linux version 2.6.34 (root@LucidSRV) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #2 SMP Thu May 27
> 09:56:26 MSD 2010
> [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.34 root=UUID=8ab02f1a-d6bd-4829-9732-20440acf320f ro
> console=tty0
> [ 0.000000] BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> [ 0.000000] BIOS-e820: 0000000000100000 - 0000000080000000 (usable)
> [ 0.000000] BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] DMI 2.4 present.
> [ 0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
> [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> [ 0.000000] No AGP bridge found
> [ 0.000000] last_pfn = 0x80000 max_arch_pfn = 0x400000000
> [ 0.000000] MTRR default type: write-back
> [ 0.000000] MTRR fixed ranges enabled:
> [ 0.000000] 00000-9FFFF write-back
> [ 0.000000] A0000-BFFFF write-combining
> [ 0.000000] C0000-FFFFF write-back
> [ 0.000000] MTRR variable ranges enabled:
> [ 0.000000] 0 base 0F0000000 mask FF8000000 uncachable
> [ 0.000000] 1 base 0F8000000 mask FFC000000 uncachable
> [ 0.000000] 2 disabled
> [ 0.000000] 3 disabled
> [ 0.000000] 4 disabled
> [ 0.000000] 5 disabled
> [ 0.000000] 6 disabled
> [ 0.000000] 7 disabled
> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> [ 0.000000] e820 update range: 0000000000001000 - 0000000000010000 (usable) ==> (reserved)
> [ 0.000000] Scanning 1 areas for low memory corruption
> [ 0.000000] modified physical RAM map:
> [ 0.000000] modified: 0000000000000000 - 0000000000010000 (reserved)
> [ 0.000000] modified: 0000000000010000 - 000000000009fc00 (usable)
> [ 0.000000] modified: 000000000009fc00 - 00000000000a0000 (reserved)
> [ 0.000000] modified: 00000000000e0000 - 0000000000100000 (reserved)
> [ 0.000000] modified: 0000000000100000 - 0000000080000000 (usable)
> [ 0.000000] modified: 00000000fc000000 - 0000000100000000 (reserved)
> [ 0.000000] initial memory mapped : 0 - 20000000
> [ 0.000000] found SMP MP-table at [ffff8800000fbc60] fbc60
> [ 0.000000] init_memory_mapping: 0000000000000000-0000000080000000
> [ 0.000000] 0000000000 - 0080000000 page 2M
> [ 0.000000] kernel direct mapping tables up to 80000000 @ 16000-19000
> [ 0.000000] RAMDISK: 33f01000 - 37ff0000
> [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen)
> [ 0.000000] ACPI: XSDT 00000000fc012cb0 00034 (v01 Xen HVM 00000000 HVML 00000000)
> [ 0.000000] ACPI: FACP 00000000fc012ad0 000F4 (v04 Xen HVM 00000000 HVML 00000000)
> [ 0.000000] ACPI: DSDT 00000000fc002c40 0FE0B (v02 Xen HVM 00000000 INTL 20090123)
> [ 0.000000] ACPI: FACS 00000000fc002c00 00040
> [ 0.000000] ACPI: APIC 00000000fc012bd0 000D8 (v02 Xen HVM 00000000 HVML 00000000)
> [ 0.000000] ACPI: Local APIC address 0xfee00000
> [ 0.000000] No NUMA configuration found
> [ 0.000000] Faking a node at 0000000000000000-0000000080000000
> [ 0.000000] Initmem setup node 0 0000000000000000-0000000080000000
> [ 0.000000] NODE_DATA [0000000001cb20c0 - 0000000001cb70bf]
> [ 0.000000] [ffffea0000000000-ffffea0001bfffff] PMD -> [ffff880002600000-ffff8800041fffff] on node 0
> [ 0.000000] Zone PFN ranges:
> [ 0.000000] DMA 0x00000010 -> 0x00001000
> [ 0.000000] DMA32 0x00001000 -> 0x00100000
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start PFN for each node
> [ 0.000000] early_node_map[2] active PFN ranges
> [ 0.000000] 0: 0x00000010 -> 0x0000009f
> [ 0.000000] 0: 0x00000100 -> 0x00080000
> [ 0.000000] On node 0 totalpages: 524175
> [ 0.000000] DMA zone: 56 pages used for memmap
> [ 0.000000] DMA zone: 0 pages reserved
> [ 0.000000] DMA zone: 3927 pages, LIFO batch:0
> [ 0.000000] DMA32 zone: 7112 pages used for memmap
> [ 0.000000] DMA32 zone: 513080 pages, LIFO batch:31
> [ 0.000000] ACPI: PM-Timer IO Port: 0x1f48
> [ 0.000000] ACPI: Local APIC address 0xfee00000
> [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
> [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
> [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
> [ 0.000000] ACPI: IRQ0 used by override.
> [ 0.000000] ACPI: IRQ2 used by override.
> [ 0.000000] ACPI: IRQ5 used by override.
> [ 0.000000] ACPI: IRQ9 used by override.
> [ 0.000000] ACPI: IRQ10 used by override.
> [ 0.000000] ACPI: IRQ11 used by override.
> [ 0.000000] Using ACPI (MADT) for SMP configuration information
> [ 0.000000] SMP: Allowing 15 CPUs, 13 hotplug CPUs
> [ 0.000000] nr_irqs_gsi: 48
> [ 0.000000] Xen version 4.0.
> =>[ 0.000000] Xen Platform PCI: I/O protocol version 1
> =>[ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
> => [ 0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
> =>[ 0.000000] You might have to change the root device
> =>[ 0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
> [ 0.000000] in your root= kernel command line option
> [ 0.000000] Xen doesn't support pvclock on HVM,disable pv timer
> [ 0.000000] early_res array is doubled to 64 at [17180 - 1797f]
> ....
>
> "df -h" reports /dev/xvda(X) devices
>
>
everything seems fine, the callback mechanism seems to be working too
(even though I am not writing an explicit message about it, maybe I
should). Please post the output of 'cat /proc/interrupts' just to be
sure...
-----Inline Attachment Follows-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 16656 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-27 13:06 ` Boris Derzhavets
@ 2010-05-27 14:58 ` Stefano Stabellini
2010-05-27 15:11 ` Boris Derzhavets
2010-05-27 15:16 ` Boris Derzhavets
0 siblings, 2 replies; 25+ messages in thread
From: Stefano Stabellini @ 2010-05-27 14:58 UTC (permalink / raw)
To: Boris Derzhavets
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]
On Thu, 27 May 2010, Boris Derzhavets wrote:
> root@LucidSRV:~# cat /proc/interrupts
> CPU0 CPU1
> 0: 29 0 IO-APIC-edge timer
> 1: 107 0 IO-APIC-edge i8042
> 4: 1 0 IO-APIC-edge
> 6: 2 0 IO-APIC-edge floppy
> 8: 0 0 IO-APIC-edge rtc0
> 9: 0 0 IO-APIC-fasteoi acpi
> 12: 187 496 IO-APIC-edge i8042
> 14: 0 0 IO-APIC-edge ata_piix
> 15: 933 0 IO-APIC-edge ata_piix
> 16: 293 0 xen-dyn-event xenbus
> 17: 5059 0 xen-dyn-event blkif
> 18: 0 0 xen-dyn-event blkif
> 19: 72 0 xen-dyn-event eth0
> 23: 0 0 IO-APIC-fasteoi uhci_hcd:usb1
> 36: 0 0 IO-APIC-fasteoi Ensoniq AudioPCI
> NMI: 0 0 Non-maskable interrupts
> LOC: 2767 2901 Local timer interrupts
> SPU: 0 0 Spurious interrupts
> PMI: 0 0 Performance monitoring interrupts
> PND: 0 0 Performance pending work
> PLT: 5211 0 Platform interrupts
> RES: 1189 1949 Rescheduling interrupts
> CAL: 130 89 Function call interrupts
> TLB: 230 179 TLB shootdowns
> TRM: 0 0 Thermal event interrupts
> THR: 0 0 Threshold APIC interrupts
> MCE: 0 0 Machine check exceptions
> MCP: 1 1 Machine check polls
> ERR: 0
> MIS: 0
>
You definitely have the vector callback enabled.
I am not sure why you receive so many ata_piix interrupts given that you
shouldn't be using the emulated disk at all.
Maybe you are reading from an emulated cdrom?
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-27 14:58 ` Stefano Stabellini
@ 2010-05-27 15:11 ` Boris Derzhavets
2010-05-27 15:16 ` Boris Derzhavets
1 sibling, 0 replies; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-27 15:11 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 3051 bytes --]
Dmesg log ( attached to my first report ) also shows :-
[ 2.932460] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc320 irq 14
[ 2.933404] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc328 irq 15
I am not using emulated CDROM . Originally HVM was installed via virt-install using
ISO image. Nothing else.
I will verify "virsh dumpxml LucidHVM" one more time ( shortly).
Boris.
--- On Thu, 5/27/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Thursday, May 27, 2010, 10:58 AM
On Thu, 27 May 2010, Boris Derzhavets wrote:
> root@LucidSRV:~# cat /proc/interrupts
> CPU0 CPU1
> 0: 29 0 IO-APIC-edge timer
> 1: 107 0 IO-APIC-edge i8042
> 4: 1 0 IO-APIC-edge
> 6: 2 0 IO-APIC-edge floppy
> 8: 0 0 IO-APIC-edge rtc0
> 9: 0 0 IO-APIC-fasteoi acpi
> 12: 187 496 IO-APIC-edge i8042
> 14: 0 0 IO-APIC-edge ata_piix
> 15: 933 0 IO-APIC-edge ata_piix
> 16: 293 0 xen-dyn-event xenbus
> 17: 5059 0 xen-dyn-event blkif
> 18: 0 0 xen-dyn-event blkif
> 19: 72 0 xen-dyn-event eth0
> 23: 0 0 IO-APIC-fasteoi uhci_hcd:usb1
> 36: 0 0 IO-APIC-fasteoi Ensoniq AudioPCI
> NMI: 0 0 Non-maskable interrupts
> LOC: 2767 2901 Local timer interrupts
> SPU: 0 0 Spurious interrupts
> PMI: 0 0 Performance monitoring interrupts
> PND: 0 0 Performance pending work
> PLT: 5211 0 Platform interrupts
> RES: 1189 1949 Rescheduling interrupts
> CAL: 130 89 Function call interrupts
> TLB: 230 179 TLB shootdowns
> TRM: 0 0 Thermal event interrupts
> THR: 0 0 Threshold APIC interrupts
> MCE: 0 0 Machine check exceptions
> MCP: 1 1 Machine check polls
> ERR: 0
> MIS: 0
>
You definitely have the vector callback enabled.
I am not sure why you receive so many ata_piix interrupts given that you
shouldn't be using the emulated disk at all.
Maybe you are reading from an emulated cdrom?
-----Inline Attachment Follows-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 7031 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-27 14:58 ` Stefano Stabellini
2010-05-27 15:11 ` Boris Derzhavets
@ 2010-05-27 15:16 ` Boris Derzhavets
2010-05-28 15:59 ` Stefano Stabellini
1 sibling, 1 reply; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-27 15:16 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 4100 bytes --]
Here we go:-
<domain type="xen" id="4">
<name>LucidHVM</name>
<uuid>0f26e840-836d-18f3-9438-0f12d1e42677</uuid>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>2</vcpu>
<os>
<type>hvm</type>
<loader>/usr/lib/xen/boot/hvmloader</loader>
<boot dev="hd"/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset="utc"/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
************************************************************
<disk type="block" device="disk">
<driver name="phy"/>
<source dev="/dev/sda7"/>
<target dev="hda" bus="ide"/>
</disk>
<disk type="file" device="cdrom">
<target dev="hdc" bus="ide"/>
<readonly/>
*************************************************************
</disk>
<interface type="bridge">
<mac address="00:16:36:2a:cd:af"/>
<source bridge="br0"/>
<script path="/etc/xen/scripts/vif-bridge"/>
<target dev="vif4.0"/>
</interface>
<serial type="pty">
<source path="/dev/pts/0"/>
<target port="0"/>
</serial>
<console type="pty" tty="/dev/pts/0">
<source path="/dev/pts/0"/>
<target port="0"/>
</console>
<input type="mouse" bus="ps2"/>
<graphics type="vnc" port="5900" autoport="yes" keymap="en-us"/>
<sound model="es1370"/>
</devices>
</domain>
That's XML profile kept by virt-manager after it's own install HVM DomU on F13
Boris.
--- On Thu, 5/27/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Thursday, May 27, 2010, 10:58 AM
On Thu, 27 May 2010, Boris Derzhavets wrote:
> root@LucidSRV:~# cat /proc/interrupts
> CPU0 CPU1
> 0: 29 0 IO-APIC-edge timer
> 1: 107 0 IO-APIC-edge i8042
> 4: 1 0 IO-APIC-edge
> 6: 2 0 IO-APIC-edge floppy
> 8: 0 0 IO-APIC-edge rtc0
> 9: 0 0 IO-APIC-fasteoi acpi
> 12: 187 496 IO-APIC-edge i8042
> 14: 0 0 IO-APIC-edge ata_piix
> 15: 933 0 IO-APIC-edge ata_piix
> 16: 293 0 xen-dyn-event xenbus
> 17: 5059 0 xen-dyn-event blkif
> 18: 0 0 xen-dyn-event blkif
> 19: 72 0 xen-dyn-event eth0
> 23: 0 0 IO-APIC-fasteoi uhci_hcd:usb1
> 36: 0 0 IO-APIC-fasteoi Ensoniq AudioPCI
> NMI: 0 0 Non-maskable interrupts
> LOC: 2767 2901 Local timer interrupts
> SPU: 0 0 Spurious interrupts
> PMI: 0 0 Performance monitoring interrupts
> PND: 0 0 Performance pending work
> PLT: 5211 0 Platform interrupts
> RES: 1189 1949 Rescheduling interrupts
> CAL: 130 89 Function call interrupts
> TLB: 230 179 TLB shootdowns
> TRM: 0 0 Thermal event interrupts
> THR: 0 0 Threshold APIC interrupts
> MCE: 0 0 Machine check exceptions
> MCP: 1 1 Machine check polls
> ERR: 0
> MIS: 0
>
You definitely have the vector callback enabled.
I am not sure why you receive so many ata_piix interrupts given that you
shouldn't be using the emulated disk at all.
Maybe you are reading from an emulated cdrom?
-----Inline Attachment Follows-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 8500 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-27 15:16 ` Boris Derzhavets
@ 2010-05-28 15:59 ` Stefano Stabellini
0 siblings, 0 replies; 25+ messages in thread
From: Stefano Stabellini @ 2010-05-28 15:59 UTC (permalink / raw)
To: Boris Derzhavets
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
On Thu, 27 May 2010, Boris Derzhavets wrote:
> <disk type="block" device="disk">
> <driver name="phy"/>
> <source dev="/dev/sda7"/>
> <target dev="hda" bus="ide"/>
> </disk>
> <disk type="file" device="cdrom">
> <target dev="hdc" bus="ide"/>
> <readonly/>
I am pretty sure that the interrupts on the ata_piix device are due to
the cdrom that has been used through the emulated interface.
Using xend/xl, it is possible to make sure your guest can use the pv
interface for the cdrom too, specifying xvdc instead of hdc as virtual
device:
disk = [ 'file:/path/to/iso,xvdc:cdrom,r' ]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] xen: implement vector callback for evtchn delivery
@ 2010-05-27 6:51 Boris Derzhavets
0 siblings, 0 replies; 25+ messages in thread
From: Boris Derzhavets @ 2010-05-27 6:51 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, Keir Fraser, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 1190 bytes --]
Xen 4.0 updated with yours patch on top of F13. Ubuntu Lucid HVM created.
Kernel 2.6.34 been built on HVM per yours the most recent instructions.
HVM reloaded with 2.6.34 kernel. Obvious network performance improvement.
Disk I/O doesn't look much better.
Boris.
--- On Wed, 5/26/10, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <Keir.Fraser@eu.citrix.com>, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Date: Wednesday, May 26, 2010, 7:12 AM
On Wed, 26 May 2010, Boris Derzhavets wrote:
> When i run rpmbuild on F13 , i need pv-on-hvm.patch in SOURCES for xen-4.0.0.1.7.f12.src.rpm.
> That was a reason of my request yesterday.
>
I am attaching to this email an untested port of the patch to 4.0.
-----Inline Attachment Follows-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 1808 bytes --]
[-- Attachment #2: config.34.gz --]
[-- Type: application/x-gzip, Size: 29329 bytes --]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: LucidHVM.xml --]
[-- Type: text/xml; name="LucidHVM.xml", Size: 1361 bytes --]
<domain type='xen' id='4'>
<name>LucidHVM</name>
<uuid>0f26e840-836d-18f3-9438-0f12d1e42677</uuid>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>2</vcpu>
<os>
<type>hvm</type>
<loader>/usr/lib/xen/boot/hvmloader</loader>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
<disk type='block' device='disk'>
<driver name='phy'/>
<source dev='/dev/sda7'/>
<target dev='hda' bus='ide'/>
</disk>
<disk type='file' device='cdrom'>
<target dev='hdc' bus='ide'/>
<readonly/>
</disk>
<interface type='bridge'>
<mac address='00:16:36:2a:cd:af'/>
<source bridge='br0'/>
<script path='/etc/xen/scripts/vif-bridge'/>
<target dev='vif4.0'/>
</interface>
<serial type='pty'>
<source path='/dev/pts/0'/>
<target port='0'/>
</serial>
<console type='pty' tty='/dev/pts/0'>
<source path='/dev/pts/0'/>
<target port='0'/>
</console>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='5900' autoport='yes' keymap='en-us'/>
<sound model='es1370'/>
</devices>
</domain>
[-- Attachment #4: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH] xen: implement vector callback for evtchn delivery
@ 2010-05-10 14:27 Stefano Stabellini
2010-05-10 15:17 ` Jan Beulich
0 siblings, 1 reply; 25+ messages in thread
From: Stefano Stabellini @ 2010-05-10 14:27 UTC (permalink / raw)
To: xen-devel
Hi all,
this patch implements the vector callback mechanism in Xen and it is based
on Sheng's work so he should be considered the original author.
I realize now that the tsc_mode patch I sent before only applies on top
of this one.
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -185,16 +185,16 @@
void hvm_assert_evtchn_irq(struct vcpu *v)
{
- if ( v->vcpu_id != 0 )
- return;
-
if ( unlikely(in_irq() || !local_irq_is_enabled()) )
{
tasklet_schedule(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
return;
}
- hvm_set_callback_irq_level(v);
+ if (is_hvm_pv_evtchn_vcpu(v))
+ vcpu_kick(v);
+ else
+ hvm_set_callback_irq_level(v);
}
void hvm_set_pci_link_route(struct domain *d, u8 link, u8 isa_irq)
@@ -251,7 +251,7 @@
via_type = (uint8_t)(via >> 56) + 1;
if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
- (via_type > HVMIRQ_callback_pci_intx) )
+ (via_type > HVMIRQ_callback_vector) )
via_type = HVMIRQ_callback_none;
spin_lock(&d->arch.hvm_domain.irq_lock);
@@ -297,6 +297,9 @@
if ( hvm_irq->callback_via_asserted )
__hvm_pci_intx_assert(d, pdev, pintx);
break;
+ case HVMIRQ_callback_vector:
+ hvm_irq->callback_via.vector = (uint8_t)via;
+ break;
default:
break;
}
@@ -312,6 +315,10 @@
case HVMIRQ_callback_pci_intx:
printk("PCI INTx Dev 0x%02x Int%c\n", pdev, 'A' + pintx);
break;
+ case HVMIRQ_callback_vector:
+ printk("Set HVMIRQ_callback_vector to %u\n",
+ hvm_irq->callback_via.vector);
+ break;
default:
printk("None\n");
break;
@@ -323,6 +330,10 @@
struct hvm_domain *plat = &v->domain->arch.hvm_domain;
int vector;
+ if (plat->irq.callback_via_type == HVMIRQ_callback_vector &&
+ vcpu_info(v, evtchn_upcall_pending))
+ return hvm_intack_vector(plat->irq.callback_via.vector);
+
if ( unlikely(v->nmi_pending) )
return hvm_intack_nmi;
@@ -363,6 +374,8 @@
case hvm_intsrc_lapic:
if ( !vlapic_ack_pending_irq(v, intack.vector) )
intack = hvm_intack_none;
+ break;
+ case hvm_intsrc_vector:
break;
default:
intack = hvm_intack_none;
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -164,7 +164,8 @@
{
HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
vmx_inject_extint(intack.vector);
- pt_intr_post(v, intack);
+ if (intack.source != hvm_intsrc_vector)
+ pt_intr_post(v, intack);
}
/* Is there another IRQ to queue up behind this one? */
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -243,6 +243,8 @@
fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
(1U << XENFEAT_highmem_assist) |
(1U << XENFEAT_gnttab_map_avail_bits);
+ else
+ fi.submap |= (1U << XENFEAT_hvm_callback_vector);
#endif
break;
default:
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -33,7 +33,8 @@
hvm_intsrc_pic,
hvm_intsrc_lapic,
hvm_intsrc_nmi,
- hvm_intsrc_mce
+ hvm_intsrc_mce,
+ hvm_intsrc_vector
};
struct hvm_intack {
uint8_t source; /* enum hvm_intsrc */
@@ -44,6 +45,7 @@
#define hvm_intack_lapic(vec) ( (struct hvm_intack) { hvm_intsrc_lapic, vec } )
#define hvm_intack_nmi ( (struct hvm_intack) { hvm_intsrc_nmi, 2 } )
#define hvm_intack_mce ( (struct hvm_intack) { hvm_intsrc_mce, 18 } )
+#define hvm_intack_vector(vec)( (struct hvm_intack) { hvm_intsrc_vector, vec } )
enum hvm_intblk {
hvm_intblk_none, /* not blocked (deliverable) */
hvm_intblk_shadow, /* MOV-SS or STI shadow */
diff --git a/xen/include/asm-x86/hvm/irq.h b/xen/include/asm-x86/hvm/irq.h
--- a/xen/include/asm-x86/hvm/irq.h
+++ b/xen/include/asm-x86/hvm/irq.h
@@ -54,12 +54,14 @@
enum {
HVMIRQ_callback_none,
HVMIRQ_callback_gsi,
- HVMIRQ_callback_pci_intx
+ HVMIRQ_callback_pci_intx,
+ HVMIRQ_callback_vector
} callback_via_type;
};
union {
uint32_t gsi;
struct { uint8_t dev, intx; } pci;
+ uint32_t vector;
} callback_via;
/* Number of INTx wires asserting each PCI-ISA link. */
diff --git a/xen/include/public/features.h b/xen/include/public/features.h
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -68,6 +68,9 @@
*/
#define XENFEAT_gnttab_map_avail_bits 7
+/* x86: Does this Xen host support the HVM callback vector type? */
+#define XENFEAT_hvm_callback_vector 8
+
#define XENFEAT_NR_SUBMAPS 1
#endif /* __XEN_PUBLIC_FEATURES_H__ */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -592,6 +592,9 @@
#define VM_ASSIST(_d,_t) (test_bit((_t), &(_d)->vm_assist))
#define is_hvm_domain(d) ((d)->is_hvm)
+#define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \
+ d->arch.hvm_domain.irq.callback_via_type == HVMIRQ_callback_vector)
+#define is_hvm_pv_evtchn_vcpu(v) (is_hvm_pv_evtchn_domain(v->domain))
#define is_hvm_vcpu(v) (is_hvm_domain(v->domain))
#define need_iommu(d) ((d)->need_iommu)
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-10 14:27 Stefano Stabellini
@ 2010-05-10 15:17 ` Jan Beulich
2010-05-11 11:11 ` Stefano Stabellini
0 siblings, 1 reply; 25+ messages in thread
From: Jan Beulich @ 2010-05-10 15:17 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel
>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> 10.05.10 16:27 >>>
>--- a/xen/arch/x86/hvm/irq.c
>+++ b/xen/arch/x86/hvm/irq.c
>@@ -185,16 +185,16 @@
>
> void hvm_assert_evtchn_irq(struct vcpu *v)
> {
>- if ( v->vcpu_id != 0 )
>- return;
>-
Shouldn't this conditional move ...
> if ( unlikely(in_irq() || !local_irq_is_enabled()) )
> {
> tasklet_schedule(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
> return;
> }
>
>- hvm_set_callback_irq_level(v);
>+ if (is_hvm_pv_evtchn_vcpu(v))
>+ vcpu_kick(v);
>+ else
... here? I can't immediately see other changes in this patch
preventing the checked for condition from happening.
>+ hvm_set_callback_irq_level(v);
> }
>
> void hvm_set_pci_link_route(struct domain *d, u8 link, u8 isa_irq)
Jan
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] xen: implement vector callback for evtchn delivery
2010-05-10 15:17 ` Jan Beulich
@ 2010-05-11 11:11 ` Stefano Stabellini
0 siblings, 0 replies; 25+ messages in thread
From: Stefano Stabellini @ 2010-05-11 11:11 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel@lists.xensource.com, Stefano Stabellini
On Mon, 10 May 2010, Jan Beulich wrote:
> >>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> 10.05.10 16:27 >>>
> >--- a/xen/arch/x86/hvm/irq.c
> >+++ b/xen/arch/x86/hvm/irq.c
> >@@ -185,16 +185,16 @@
> >
> > void hvm_assert_evtchn_irq(struct vcpu *v)
> > {
> >- if ( v->vcpu_id != 0 )
> >- return;
> >-
>
> Shouldn't this conditional move ...
>
> > if ( unlikely(in_irq() || !local_irq_is_enabled()) )
> > {
> > tasklet_schedule(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
> > return;
> > }
> >
> >- hvm_set_callback_irq_level(v);
> >+ if (is_hvm_pv_evtchn_vcpu(v))
> >+ vcpu_kick(v);
> >+ else
>
> ... here? I can't immediately see other changes in this patch
> preventing the checked for condition from happening.
>
Yes you are right, thank you.
I'll send the patch again with the fix included.
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2010-05-28 17:21 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-18 10:31 [PATCH] xen: implement vector callback for evtchn delivery Stefano Stabellini
2010-05-24 18:59 ` Keir Fraser
2010-05-25 9:55 ` Stefano Stabellini
2010-05-26 6:51 ` Boris Derzhavets
2010-05-26 7:31 ` Keir Fraser
2010-05-26 9:58 ` Boris Derzhavets
2010-05-26 11:12 ` Stefano Stabellini
2010-05-26 12:02 ` Boris Derzhavets
2010-05-26 12:07 ` Boris Derzhavets
-- strict thread matches above, loose matches on Subject: below --
2010-05-28 16:46 Boris Derzhavets
2010-05-28 16:55 ` Stefano Stabellini
2010-05-28 17:13 ` Boris Derzhavets
2010-05-28 17:21 ` Stefano Stabellini
2010-05-28 17:19 ` Boris Derzhavets
2010-05-27 8:57 Boris Derzhavets
2010-05-27 12:06 ` Stefano Stabellini
2010-05-27 13:06 ` Boris Derzhavets
2010-05-27 14:58 ` Stefano Stabellini
2010-05-27 15:11 ` Boris Derzhavets
2010-05-27 15:16 ` Boris Derzhavets
2010-05-28 15:59 ` Stefano Stabellini
2010-05-27 6:51 Boris Derzhavets
2010-05-10 14:27 Stefano Stabellini
2010-05-10 15:17 ` Jan Beulich
2010-05-11 11:11 ` Stefano Stabellini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).