WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [Qemu-devel] [RfC / Patch] xenner: event channel impleme

To: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Subject: [Xen-devel] Re: [Qemu-devel] [RfC / Patch] xenner: event channel implementation.
From: Avi Kivity <avi@xxxxxxxxxx>
Date: Wed, 22 Apr 2009 19:23:33 +0300
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>
Delivery-date: Wed, 22 Apr 2009 09:24:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49EF1EE6.5080900@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <49EF1EE6.5080900@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Gerd Hoffmann wrote:
  Hi,

Merging the xen bits seems to be on a good way. Time to look at un-bitrotting the xenner bits ...

Here is a first patch for comments. Not useful on its own. Right now I'm looking more for comments on the way the integration is done.

Event channels on Xen are managed by calling the xc_evtchn_* functions provided by libxenctrl. The library in turn does does hypercalls into the xen kernel. xenner obviously has to provide an alternative implementation for these functions. Also for others. This patch starts with just the event channels though.

It works this way: There is a struct with function pointers to the event channel functions. The struct can be switched at runtime to the xen or xenner version of the functions depending on the qemu operation mode.

The struct is named "xc_evtchn", the function pointer are named like the xc_evtchn_* functions, but without the xc_evtchn_ prefix, i.e. "xc_evtchn_open(...)" becomes xc_evtchn.open(...).

The function calls in the source code (xen backend drivers) are not changed directly, but using a include file with a bunch of #defines. That way I don't have to change s/xc_evtchn_/xc_evtchn./ all over the place. Also xenner can easily be disabled at compile time and the indirect function pointer calls simply go away then.


I don't think the last bit is worthwhile. Function pointers these days are pretty fast, their cost will be dwarfed by the syscall and hypercall overhead.

pecific
@@ -422,7 +423,9 @@ for opt do
   ;;
   --disable-kqemu) kqemu="no"
   ;;
-  --disable-xen) xen="no"
+  --disable-xen) xen="no"; xenner="no"
+  ;;
+  --disable-xenner) xenner="no"

It would be nice to be able to build without the original Xen libraries.


+
+static struct domain *get_domain(int domid)
+{
+    struct domain *domain;
+
+    TAILQ_FOREACH(domain, &domains, list) {
+    if (domain->domid == domid)
+        goto done;
+    }
+
+    domain = qemu_mallocz(sizeof(*domain));
+    if (domid)
+    domain->domid = domid;
+    TAILQ_INSERT_TAIL(&domains, domain, list);
+    if (debug)
+    qemu_log("xen ev:  ?: new domain id %d\n", domain->domid);
+
+done:
+    domain->refcount++;
+    return domain;
+}

Curious, can there be any domain other than the guest and the fake dom0 you're emulating?



--
error compiling committee.c: too many arguments to function


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