[PATCH] abstract request_evtchn

[PATCH] abstract request_evtchn

[Matt Chapman]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

This patch provides request_evtchn and free_evtchn, intended
to be used instead of bind_evtchn_to_irq/request_irq and
free_irq/unbind_evtchn_from_irq.  This allows architectures
to implement event channels as they see fit, not necessarily
using Linux IRQs.

Tested to still work on x86.

Matt


[-- Attachment #2: blk2.diff --]
[-- Type: text/plain, Size: 4504 bytes --]

diff -r 12122e34b96f linux-2.6-xen-sparse/arch/xen/kernel/evtchn.c
--- a/linux-2.6-xen-sparse/arch/xen/kernel/evtchn.c	Thu Jul 14 22:33:25 2005
+++ b/linux-2.6-xen-sparse/arch/xen/kernel/evtchn.c	Thu Jul 14 16:51:46 2005
@@ -341,6 +341,20 @@
     spin_unlock(&irq_mapping_update_lock);
 }
 
+int request_evtchn(int evtchn, evtchn_handler handler,
+                   unsigned long irqflags, const char * devname, void *dev_id)
+{
+    int irq = bind_evtchn_to_irq(evtchn);
+    return request_irq(irq, handler, irqflags, devname, dev_id);
+}
+
+void free_evtchn(int evtchn, void *dev_id)
+{
+    int irq = evtchn_to_irq[evtchn];
+    free_irq(irq, dev_id);
+    unbind_evtchn_from_irq(evtchn);
+}
+
 static void do_nothing_function(void *ign)
 {
 }
diff -r 12122e34b96f linux-2.6-xen-sparse/drivers/xen/blkback/common.h
--- a/linux-2.6-xen-sparse/drivers/xen/blkback/common.h	Thu Jul 14 22:33:25 2005
+++ b/linux-2.6-xen-sparse/drivers/xen/blkback/common.h	Thu Jul 14 16:51:46 2005
@@ -42,7 +42,6 @@
     /* Physical parameters of the comms window. */
     unsigned long     shmem_frame;
     unsigned int      evtchn;
-    int               irq;
     /* Comms information. */
     blkif_back_ring_t blk_ring;
     /* VBDs attached to this interface. */
diff -r 12122e34b96f linux-2.6-xen-sparse/drivers/xen/blkback/interface.c
--- a/linux-2.6-xen-sparse/drivers/xen/blkback/interface.c	Thu Jul 14 22:33:25 2005
+++ b/linux-2.6-xen-sparse/drivers/xen/blkback/interface.c	Thu Jul 14 16:51:46 2005
@@ -38,7 +38,7 @@
      * may be outstanding requests at the disc whose asynchronous responses
      * must still be notified to the remote driver.
      */
-    unbind_evtchn_from_irq(blkif->evtchn);
+    free_evtchn(blkif->evtchn, blkif);
 
 #ifdef CONFIG_XEN_BLKDEV_GRANT
     {
@@ -247,12 +247,11 @@
     BACK_RING_INIT(&blkif->blk_ring, sring, PAGE_SIZE);
     
     blkif->evtchn        = evtchn;
-    blkif->irq           = bind_evtchn_to_irq(evtchn);
     blkif->shmem_frame   = shmem_frame;
     blkif->status        = CONNECTED;
     blkif_get(blkif);
 
-    request_irq(blkif->irq, blkif_be_int, 0, "blkif-backend", blkif);
+    request_evtchn(blkif->evtchn, blkif_be_int, 0, "blkif-backend", blkif);
 
     connect->status = BLKIF_BE_STATUS_OKAY;
 }
@@ -277,7 +276,6 @@
         blkif->status = DISCONNECTING;
         blkif->disconnect_rspid = rsp_id;
         wmb(); /* Let other CPUs see the status change. */
-        free_irq(blkif->irq, blkif);
         blkif_deschedule(blkif);
         blkif_put(blkif);
         return 0; /* Caller should not send response message. */
diff -r 12122e34b96f linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c
--- a/linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c	Thu Jul 14 22:33:25 2005
+++ b/linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c	Thu Jul 14 16:51:46 2005
@@ -78,7 +78,6 @@
 static int blkif_handle = 0;
 static unsigned int blkif_state = BLKIF_STATE_CLOSED;
 static unsigned int blkif_evtchn = 0;
-static unsigned int blkif_irq = 0;
 
 static int blkif_control_rsp_valid;
 static blkif_response_t blkif_control_rsp;
@@ -1159,10 +1158,7 @@
         free_page((unsigned long)blk_ring.sring);
         blk_ring.sring = NULL;
     }
-    free_irq(blkif_irq, NULL);
-    blkif_irq = 0;
-    
-    unbind_evtchn_from_irq(blkif_evtchn);
+    free_evtchn(blkif_evtchn, NULL);
     blkif_evtchn = 0;
 }
 
@@ -1266,12 +1262,11 @@
     int err = 0;
 
     blkif_evtchn = status->evtchn;
-    blkif_irq    = bind_evtchn_to_irq(blkif_evtchn);
-
-    err = request_irq(blkif_irq, blkif_int, SA_SAMPLE_RANDOM, "blkif", NULL);
+
+    err = request_evtchn(blkif_evtchn, blkif_int, SA_SAMPLE_RANDOM, "blkif", NULL);
     if ( err )
     {
-        WPRINTK("request_irq failed (err=%d)\n", err);
+        WPRINTK("request_evtchn failed (err=%d)\n", err);
         return;
     }
 
diff -r 12122e34b96f linux-2.6-xen-sparse/include/asm-xen/evtchn.h
--- a/linux-2.6-xen-sparse/include/asm-xen/evtchn.h	Thu Jul 14 22:33:25 2005
+++ b/linux-2.6-xen-sparse/include/asm-xen/evtchn.h	Thu Jul 14 16:51:46 2005
@@ -41,6 +41,11 @@
 /*
  * LOW-LEVEL DEFINITIONS
  */
+
+/* Binding to event channels */
+typedef int (*evtchn_handler)(int dummy, void *dev_id, struct pt_regs *regs);
+int request_evtchn(int evtchn, evtchn_handler handler, unsigned long irqflags, const char *devname, void *dev_id);
+void free_evtchn(int evtchn, void *dev_id);
 
 /* Entry point for notifications into Linux subsystems. */
 asmlinkage void evtchn_do_upcall(struct pt_regs *regs);

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] abstract request_evtchn

[Keir Fraser]

On 1 Aug 2005, at 23:32, Matt Chapman wrote:

> This patch provides request_evtchn and free_evtchn, intended
> to be used instead of bind_evtchn_to_irq/request_irq and
> free_irq/unbind_evtchn_from_irq.  This allows architectures
> to implement event channels as they see fit, not necessarily
> using Linux IRQs.

Why would you not hook into the IRQ subsystem? This doesn't seem like a 
useful patch to me.

  -- Keir

Re: [PATCH] abstract request_evtchn

[Matt Chapman]

On Tue, Aug 02, 2005 at 12:43:43PM +0100, Keir Fraser wrote:
> 
> On 1 Aug 2005, at 23:32, Matt Chapman wrote:
> 
> >This patch provides request_evtchn and free_evtchn, intended
> >to be used instead of bind_evtchn_to_irq/request_irq and
> >free_irq/unbind_evtchn_from_irq.  This allows architectures
> >to implement event channels as they see fit, not necessarily
> >using Linux IRQs.
> 
> Why would you not hook into the IRQ subsystem? This doesn't seem like a 
> useful patch to me.

I'm trying to keep all the Xen drivers and related infrastructure in
modules - IMHO domains that aren't paravirtualised should be able to
use the optimised drivers too, plus it makes development easier.

irq_desc isn't exported from the Linux kernel on most architectures,
so I'm not sure how one would "hook into" the IRQ subsystem in that
way from a module.  Also, this limits the number of event channels to
NR_IRQS (minus the ones that are used in other ways).  Instead I have
the event channel subsystem register for a single IRQ and then
demultiplex internally (in the way that is already done by
evtchn_do_upcall).

Matt

Re: [PATCH] abstract request_evtchn

[Arun Sharma]

Keir Fraser wrote:
> 
> On 1 Aug 2005, at 23:32, Matt Chapman wrote:
> 
>> This patch provides request_evtchn and free_evtchn, intended
>> to be used instead of bind_evtchn_to_irq/request_irq and
>> free_irq/unbind_evtchn_from_irq.  This allows architectures
>> to implement event channels as they see fit, not necessarily
>> using Linux IRQs.
> 
> 
> Why would you not hook into the IRQ subsystem? This doesn't seem like a 
> useful patch to me.

This abstraction is useful for getting VBD/VNIF working as modules on 
unmodified Linux running on VT domains (both x86 and ia64).

	-Arun

RE: [PATCH] abstract request_evtchn

[Ling, Xiaofeng]

Matt Chapman <> wrote:
> On Tue, Aug 02, 2005 at 12:43:43PM +0100, Keir Fraser wrote:
> 
> I'm trying to keep all the Xen drivers and related infrastructure in
> modules - IMHO domains that aren't paravirtualised should be able to
> use the optimised drivers too, plus it makes development easier.  
> 
> irq_desc isn't exported from the Linux kernel on most architectures,
> so I'm not sure how one would "hook into" the IRQ subsystem in that
> way from a module.  Also, this limits the number of event channels to
> NR_IRQS (minus the ones that are used in other ways).  Instead I have
> the event channel subsystem register for a single IRQ and then
> demultiplex internally (in the way that is already done by
> evtchn_do_upcall).      

Yes, currently, when I make a frontend driver to module in unmodified 
vmx domain, I need to change request_irq to xen_request_irq, and 
use a seperate irq spaced for these para-driver.
if frontend driver use request_evtchn, then I don't need the change
and just implement a new request_evtchn(),