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


Re: [Xen-devel] Automatic loading of xen-evtchn module in Xen 4.0.0?

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] Automatic loading of xen-evtchn module in Xen 4.0.0?
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 30 Mar 2010 15:47:12 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 30 Mar 2010 15:48:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1269942297.10129.72385.camel@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>
References: <20100327173221.GJ1878@xxxxxxxxxxx> <4BAE8426.2050703@xxxxxxxx> <1269942297.10129.72385.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3
On 03/30/2010 02:44 AM, Ian Campbell wrote:
On Sat, 2010-03-27 at 22:18 +0000, Jeremy Fitzhardinge wrote:
On 03/27/2010 10:32 AM, Pasi Kärkkäinen wrote:

xend automatically mounts /proc/xen, but it doesn't try loading evtchn or 
xen-evtchn modules.
Should we add automatic loading of these modules?

xend doesn't start if xen event channel functionality is missing.

Fedora Xen rpms do load modules automatically, like this:

# cat /etc/sysconfig/modules/xen.modules

test -d /proc/xen                               || exit 0
test -f /proc/xen/capabilities                  || mount -t xenfs xen /proc/xen
test -f /proc/xen/capabilities                  || exit 0
grep -q "control_d" /proc/xen/capabilities      || exit 0

for module in xen-evtchn evtchn blkbk netbk; do
          modprobe ${module}>/dev/null 2>&1

We should be able to make these mount automatically with udev rules, I
think, but I'm not sure whether you can do udev rules to mount misc
devices (which is what /dev/xen/evtchn is).
I think you mean "modprobe misc devices" not mount.


I see various uses of the MODULE_ALIAS_MISCDEV macro in the kernel --
but I'm not sure what actually causes a matching hotplug event to be
generated, other than trying to open a matching device node which with
udev won't exist until the module is loaded.

Perhaps something in the xen core code (or xenbus?) could generate the
necessary hotplug events for the Xen "platform devices" (like the evtchn

I think the front/back xenbus and device drivers are still a bit of a
mess with regard to modules; I have to admit I tend to just compile them
all in.  It would be nice to get all that properly sorted out so they
can be sensibly modularized and auto-loaded as required.  (A good first
step would be to systematically work out what compile combinations
actually work or fail, hint, hint ;)
AFAIK the frontend driver modules work correctly as modules and distros
have been compiling them modular for a while (Debian certainly has).

Yes, I think frontend drivers are OK. But the various xenbus bits seem a bit fragile.

The situation is certainly not as rosy for *back. It'd certainly be nice
if some (or all) of the xenbus stuff could become modular too although I
would guess there will be a core which must be compiled in.

In practice there's no need to get very modular. There's some value in not loading all that backend support code unless we're actually dom0, but I don't think there's much value in getting too fine-grained beyond that. The actual drivers themselves are fairly ordinary, so they will probably just work if we can make xenbus generate the right request events. Hm, I guess that would be the tool stack setting things up for a new domain, and requesting backend devices in the process, no?

But it doesn't help for things like evtchn and gntdev. But there's no huge burden in just making the toolstack startup scripts do modprobes for them, just as it should be mounting /proc/xen.


Xen-devel mailing list