From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LwfEh-0005sG-71 for qemu-devel@nongnu.org; Wed, 22 Apr 2009 12:23:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LwfEb-0005qD-IN for qemu-devel@nongnu.org; Wed, 22 Apr 2009 12:23:45 -0400 Received: from [199.232.76.173] (port=43915 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LwfEb-0005q8-Fn for qemu-devel@nongnu.org; Wed, 22 Apr 2009 12:23:41 -0400 Received: from mx2.redhat.com ([66.187.237.31]:49003) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LwfEb-00026u-3j for qemu-devel@nongnu.org; Wed, 22 Apr 2009 12:23:41 -0400 Message-ID: <49EF4485.4080700@redhat.com> Date: Wed, 22 Apr 2009 19:23:33 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RfC / Patch] xenner: event channel implementation. References: <49EF1EE6.5080900@redhat.com> In-Reply-To: <49EF1EE6.5080900@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Xen Development Mailing List , "qemu-devel@nongnu.org" 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