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/
Home Products Support Community News


[Xen-devel] Re: [Qemu-devel] [PATCH 1/2] xenner: add event channel imple

To: qemu-devel@xxxxxxxxxx
Subject: [Xen-devel] Re: [Qemu-devel] [PATCH 1/2] xenner: add event channel implementation.
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Tue, 26 Aug 2008 12:02:45 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Gerd Hoffmann <kraxel@xxxxxxxxxx>
Delivery-date: Tue, 26 Aug 2008 04:04:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <m2n.s.1KWU8S-002Pyj@xxxxxxxxxxxxxxxxxxxxxx>
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>
Newsgroups: chiark.mail.nongnu.qemu.devel
References: <1219400728-20422-1-git-send-email-kraxel@xxxxxxxxxx> <m2n.s.1KWU8S-002Pyj@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Gerd Hoffmann writes ("[Qemu-devel] [PATCH 1/2] xenner: add event channel 
> The patch also adds a XenEvtOps struct with function pointers for the
> xc_evtchn_* family, which is used to switch between libxenctrl and the
> qemu implementation at runtime.  By default libxenctrl is used.

I don't understand why it's necessary to switch between these two
modes at runtime.  That adds a lot of extra boilerplate and
indirection code and probably has some tiny performance effect too.

Why not make it a compile-time option ?

Even if the xen qemu becomes nearly identical to upstream, version
skew issues with the hypervisor, dom0 kernel, and so on will mean that
there will have to be a separate qemu branch for xen just for release
management purposes and so on.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>