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: Avi Kivity <avi@xxxxxxxxxx>
Subject: [Xen-devel] Re: [Qemu-devel] [RfC / Patch] xenner: event channel implementation.
From: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Date: Thu, 23 Apr 2009 12:30:00 +0200
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>
Delivery-date: Thu, 23 Apr 2009 03:30:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49EF4485.4080700@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> <49EF4485.4080700@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090324 Fedora/3.0-2.1.beta2.fc11 Thunderbird/3.0b2
On 04/22/09 18:23, Avi Kivity wrote:
Gerd Hoffmann wrote:
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.

- --disable-xen) xen="no"
+ --disable-xen) xen="no"; xenner="no"

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

Hmm. I'll at least need the xen header files (at build time) anyway. Making xen and xenner independent config options and don't link the xen libraries for the !xen case should work without too much hassle (have to make the function pointers mandatory then though).

+
+static struct domain *get_domain(int domid)
+{
+ struct domain *domain;

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

No. It is the case for the current xenner implementation. The event channels are handled by a daemon then and the guests can talk to each other. This code is derived from the daemon. When moving xenner into qemu the event channels allow only host <=> guest communication, so that can probably simplified a bit. Not sure that would save that much code though. I'll have a look.

cheers,
  Gerd

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