Howdy xen folks,
I am having trouble creating a new device type (e.g., vif, vbd, vtpm). I
call this new device type "meter".
I''m using an up-to-date xen-unstable tree. When I start a guest domain
(with a "meter" domain configuration option), the startup process
hangs
for two minutes and produces a "Error: Device 0 (meter) could not be
connected. Hotplug scripts not working" message. The guest domain is then
stuck in the "paused" state until I kill it.
During this, the xenbus successfully probes the backend, and the correct
"frontend" and "frontend-id" are available to the backend on
the xenbus.
I''ve included the "xm log" error and a summary of the files
I''ve modified
below.
My questions are:
1. Have I left out modifying a necessary file when creating a new device
type?
2. Any ideas as to what could be going on that''s preventing my new
guest
domain from starting?
3. Once it''s working with dom0 as the backend, will it be possible to
start my backend in a non-dom0 domain, or is the code not to that point
yet?
I was able to create this new device on the xen-unstable tree from a month
ago, but I can''t get things going on recent trees.
Thanks for anything!
JLG
------------------------------------------------------------------------
[2005-11-12 14:38:11 xend] DEBUG (DevController:69) Waiting for devices
meter.
[2005-11-12 14:38:11 xend] DEBUG (DevController:75) Waiting for 0.
[2005-11-12 14:40:11 xend] ERROR (SrvBase:87) Request wait_for_devices
failed.
Traceback (most recent call last):
File "/usr/lib/python/xen/web/SrvBase.py", line 85, in perform
return op_method(op, req)
File "/usr/lib/python/xen/xend/server/SrvDomain.py", line 68, in
op_wait_for_devices
return self.dom.waitForDevices()
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 1200, in
waitForDevices
self.waitForDevices_(c)
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 856, in
waitForDevices_
return self.getDeviceController(deviceClass).waitForDevices()
File "/usr/lib/python/xen/xend/server/DevController.py", line 71, in
waitForDevices
return map(self.waitForDevice, self.deviceIDs())
File "/usr/lib/python/xen/xend/server/DevController.py", line 80, in
waitForDevice
raise VmError( ("Device %s (%s) could not be connected. "
VmError: Device 0 (meter) could not be connected. Hotplug scripts not
working
------------------------------------------------------------------------
I have taken the following steps:
- Edited tools/python/xen/xm/create.py to add a "meter" device to the
list
of options configuration device list:
config_devs.append([''device'',
[''meter'']])
- Edited tools/python/xen/xend/XendDomainInfo.py to add a new Meterif
controller class:
addControllerClass(''meter'', meterif.MeterifController)
- Added a new file tools/python/xen/xend/server/meterif.py with defaults
for that new class:
def getDeviceDetails(self, config):
"""@see
DevController.getDeviceDetails"""
devid = self.allocateDeviceID()
return (devid, {}, {})
def configuration(self, devid):
result = DevController.configuration(self, devid)
return result
- Added new kernel compilation options for CONFIG_XEN_METERDEV_FRONTEND
and CONFIG_XEN_METERDEV_BACKEND to the appropriate files in
linux-2.6-xen-sparse/arch/xen: Kconfig, configs/xen0_defconfig_x86_32,
configs/xenU_defconfig_x86_32, such that the "meterfront" device is
compiled into xenU kernels and the "meterback" device is compiled into
xen0 kernels.
- Added a new file
linux-2.6-xen-sparse/drivers/xen/meterfront/meterfront.c (along with
Kconfig and Makefile, following the example in the netfront directory).
The file is very simple, containing only enough code to register with the
xenbus, such as:
static struct xenbus_driver meterfront = {
.name = "meter",
.owner = THIS_MODULE,
.ids = meterfront_ids,
.probe = meterfront_probe,
.remove = meterfront_remove,
.resume = meterfront_resume,
.suspend = meterfront_suspend,
};
static void __init init_meter_xenbus(void)
{
xenbus_register_driver(&meterfront);
}
- Added a new file linux-2.6-xen-sparse/drivers/xen/meterback/meterback.c
(along with xenbus.c and Makefile, following the example in the netback
directory), again with simple entries:
void meterif_xenbus_init(void)
{
xenbus_register_backend(&meterback);
}
- Edited the file linux-2.6-xen-sparse/drivers/xen/Makefile to compile
meterfront and meterback depending on the kernel compilation options.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Sat, Nov 12, 2005 at 02:53:10PM -0500, John L Griffin wrote:> Howdy xen folks, > > I am having trouble creating a new device type (e.g., vif, vbd, vtpm). I > call this new device type "meter". > > I''m using an up-to-date xen-unstable tree. When I start a guest domain > (with a "meter" domain configuration option), the startup process hangs > for two minutes and produces a "Error: Device 0 (meter) could not be > connected. Hotplug scripts not working" message. The guest domain is then > stuck in the "paused" state until I kill it. > > During this, the xenbus successfully probes the backend, and the correct > "frontend" and "frontend-id" are available to the backend on the xenbus. > > I''ve included the "xm log" error and a summary of the files I''ve modified > below. > > My questions are: > > 1. Have I left out modifying a necessary file when creating a new device > type? > > 2. Any ideas as to what could be going on that''s preventing my new guest > domain from starting?It looks like your driver doesn''t use any hotplug scripts. The code in DevController expects all drivers to be using hotplug, and to write a node backend/<deviceClass>/<deviceID>/hotplug-status = connected when the hotplugging is complete. If you are not going to use hotplug, then the easiest way to work around this is to write this node yourself by adding it to the backend dictionary returned from MeterifController.getDeviceDetails. This will mean that you have no check that your device is working, but that sounds like exactly what you want at the moment. This check will be changing soon (though not in any major way) so we ought to be able to accommodate non-hotplug drivers more neatly.> 3. Once it''s working with dom0 as the backend, will it be possible to > start my backend in a non-dom0 domain, or is the code not to that point > yet?You lost me completely. What is it you want to do? Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan''s workaround solves my problem. For the record, here is the
necessary change in meterif.py:
def getDeviceDetails(self, config):
devid = self.allocateDeviceID()
back = { ''hotplug-status'' :
''connected'' }
return (devid, back, {})
By the way, did I miss a page that discusses this on the Xen wiki or on
this list? (I''d searched these, but to no avail.)
> You lost me completely. What is it you want to do?
I''d like to start three domains:
1. dom0 [xen0 kernel]
2. my-backend [xen0 kernel]: the meter backend domain
3. my-frontend-1 [xenU kernel]: connects to my-backend
4. my-frontend-2 [xenU kernel]: connects to my-backend
etc.
In other words, the meter backend functionality will be entirely contained
in the "my-backend" domain. My understanding of the
"netif", "blkif", and
"tpmif" domain configuration options is that they''re intended
for exactly
this purpose?
Thanks,
JLG
Ewan Mellor <ewan@xensource.com> wrote on 11/12/2005 03:19:06 PM:
> On Sat, Nov 12, 2005 at 02:53:10PM -0500, John L Griffin wrote:
>
> > Howdy xen folks,
> >
> > I am having trouble creating a new device type (e.g., vif, vbd, vtpm).
I > > call this new device type "meter".
> >
> > I''m using an up-to-date xen-unstable tree. When I start a
guest
domain > > (with a "meter" domain configuration option), the startup
process
hangs > > for two minutes and produces a "Error: Device 0 (meter) could not
be
> > connected. Hotplug scripts not working" message. The guest
domain is
then > > stuck in the "paused" state until I kill it.
> >
> > During this, the xenbus successfully probes the backend, and the
correct > > "frontend" and "frontend-id" are available to the
backend on the
xenbus.> >
> > I''ve included the "xm log" error and a summary of
the files I''ve
modified > > below.
> >
> > My questions are:
> >
> > 1. Have I left out modifying a necessary file when creating a new
device > > type?
> >
> > 2. Any ideas as to what could be going on that''s preventing
my new
guest > > domain from starting?
>
> It looks like your driver doesn''t use any hotplug scripts. The
code in
> DevController expects all drivers to be using hotplug, and to write a
node> backend/<deviceClass>/<deviceID>/hotplug-status = connected
when the
> hotplugging is complete.
>
> If you are not going to use hotplug, then the easiest way to work around
this> is to write this node yourself by adding it to the backend dictionary
returned> from MeterifController.getDeviceDetails. This will mean that you have
no> check that your device is working, but that sounds like exactly what you
want> at the moment.
>
> This check will be changing soon (though not in any major way) so we
ought to> be able to accommodate non-hotplug drivers more neatly.
>
> > 3. Once it''s working with dom0 as the backend, will it be
possible to
> > start my backend in a non-dom0 domain, or is the code not to that
point > > yet?
>
> You lost me completely. What is it you want to do?
>
> Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Sat, Nov 12, 2005 at 04:00:43PM -0500, John L Griffin wrote:> Ewan''s workaround solves my problem. For the record, here is the > necessary change in meterif.py: > > def getDeviceDetails(self, config): > devid = self.allocateDeviceID() > back = { ''hotplug-status'' : ''connected'' } > return (devid, back, {}) > > By the way, did I miss a page that discusses this on the Xen wiki or on > this list? (I''d searched these, but to no avail.)There is very little documentation of the Xen internals, I''m afraid. There are people working on API and user documentation, but the internals is pretty much last on the list. Your best bet is to ask on the list if you get stuck.> > You lost me completely. What is it you want to do? > > I''d like to start three domains: > 1. dom0 [xen0 kernel] > 2. my-backend [xen0 kernel]: the meter backend domain > 3. my-frontend-1 [xenU kernel]: connects to my-backend > 4. my-frontend-2 [xenU kernel]: connects to my-backend > etc. > > In other words, the meter backend functionality will be entirely contained > in the "my-backend" domain. My understanding of the "netif", "blkif", and > "tpmif" domain configuration options is that they''re intended for exactly > this purpose?Yes, this kind of structure should be fine. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel