thr3ads.net - Xen devel - [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery [May 2010]

If this information is useful, please help other people find it:
Share via:

Stefano Stabellini

2010-May-10 14:27 UTC

[Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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)
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Jan Beulich

2010-May-10 15:17 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2010-May-11 11:11 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2010-May-18 10:31 UTC

head link

[Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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

Keir Fraser

2010-May-24 18:59 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2010-May-25 09:55 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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

Boris Derzhavets

2010-May-26 06:51 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2010-May-26 07:31 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-May-26 09:58 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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




      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2010-May-26 11:12 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-May-26 12:02 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-May-26 12:07 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-May-27 06:51 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-May-27 08:57 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2010-May-27 12:06 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-May-27 13:06 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2010-May-27 14:58 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-May-27 15:11 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-May-27 15:16 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2010-May-28 15:59 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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

Boris Derzhavets

2010-May-28 16:46 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2010-May-28 16:55 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-May-28 17:13 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-May-28 17:19 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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



      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2010-May-28 17:21 UTC

head link

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xen devel - May 2010 - [PATCH] xen: implement vector callback for evtchn delivery

[Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

[Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery

Re: [Xen-devel] [PATCH] xen: implement vector callback for evtchn delivery