please help: initialize XEND for my debug-FE/BE.c

please help: initialize XEND for my debug-FE/BE.c

[Aggarwal, Vikas (OFT)]

Hi,

I have added a debug-Front-end.c &  debug-Back-end.c.  Also created my
debug.py based on  blkif.py

But my front-end still times out even after sending
ctrl_if_register_receiver()  to domain controller during module_init.

I think I  still did not initialize my debug.py properly.  I saw VBD
gets initialized in device_create or create_devices. Whats the
difference in the two?

Where should I look to initialize the event channel in domain
controller?

My virtual device in back-end collects the debug data and writes to file
system  so I don't  want it to be initialized during boot time via some
config file.

-vikas

Re: please help: initialize XEND for my debug-FE/BE.c

[Harry Butterworth]

To answer your questions:

I think (75% confidence) create_devices is used to create devices when a
frontend domain is started whereas device_create is used to create an
extra single device on the fly when the frontend domain is already
running.

Your frontend is probably timing out waiting to hear about interfaces
from xend.  To establish interface connections between the frontend and
backend with the current xend code you need to implement the following
basic flow:

When xend starts, it creates a controller factory for your device class.

When a frontend domain is started, the controller factory is used to
create a controller for the frontend domain.

Configured devices for your device class are attached to the controller
for the frontend domain.

Attaching the device creates the device object which in turn does a
lookup of the "backend interface" object. The backend interface object
represents the communication channel between the frontend domain and the
backend domain.  If the backend interface object does not exist it is
created at this point.  When a backend interface is created, it finds
the backend controller object for its backend domain.  If the backend
controller object does not exist it is created at this point.

Some of the drivers assume that the backend driver is already up when
the backend controller object is created and so do not listen for the
driver status up message from the backend.  I'm implementing a driver as
loadable modules so I need to use this message.

In my case, the backend driver sends a driver status up message to xend
which is handled by the backend controller object.  The backend
controller object notifies all its backend interface objects that the
backend driver is up.

When the frontend driver is initialised, it sends a driver status up
message to xend.  This is handled by the controller object. The
controller object notifies all its backend interface objects that the
frontend driver is up.

So, a backend interface object gets a driver up/down notification at
each end.  When a backend interface finds that the drivers at both its
ends are up, it can squence the establishment of the connection:

The backend interface object sends a "be create" message to the backend
to create the object representing the interface in the backend.

The backend interface object sends a "fe interface status disconnected"
message to the frontend to create the object representing the interface
in the frontend.

The frontend allocates a page for the ring interface and sends a "fe
interface connect" message to xend which is forwarded by the controller
object to the backend interface object.

xend opens an event channel between the two domains and sends a "be
connect" message to the backend passing the event channel and the
address of the page for the ring interface.

The backend responds to the be connect and the backend interface object
sends an fe interface status connected message to the frontend, passing
the event channel number.

Unloading and reloading the frontend requires that the backend stops
writing to the shared page of memory before the frontend frees it for
reuse.  In my case, the frontend sends a driver status down message,
which is handled by the controller object for the frontend. This object
notifies all the backend interface objects for that frontend which then
send be disconnect messages and wait for a response before acknowledging
back to the controller object.  The controller object waits for all
backend interfaces to complete before acknowledging the frontend driver
status down.

Unloading and reloading the backend requires that the connection is
broken and reestablished: the backend stops using the shared pages
before sending a driver status down message. The driver status down is
handled by the backend controller which notifies all the connected
backend interfaces which in turn send fe interface status disconnected
messages to their respective frontend domains.  The frontend domains
respond with fe interface connect messages, trying to reestablish a
connection.  When the back-end driver is reloaded it sends a driver
status up which is propagated to the backend interface objects which
send be create messages again and follow up with be connect messages
containing the new shared pages and fe interface status connected
messages to complete the connection.

This is just the establishment of the connection.  There are also
messages sent by the devices to create the devices in the backend after
the backend interfaces send the be create messages to create the
interfaces.

Also, this description covers the internals of xend only. The Frontend
and backend drivers must handle the messages, map the shared page,
initialise the ring interface, allocate IRQs and bind to the event
channel as appropriate.

There are a number of people working to make this simpler, in particular
Mike Wray is apparently rewriting xend and Anthony Liguori is working on
an alternative set of tools.

Also, the grant tables implementation probably means that the above
description is out of date.  I've not investigated grant tables much
yet.

I've not been following the checkins to unstable since the xen summit so
I'll have missed anything not mentioned on the mailing list or IRC.

The current overhead in terms of client code to establish an entity on
the xen inter-domain communication "bus" is currently of the order of
1000 statements (counting FE, BE and slice of xend).  A better
inter-domain communication API could reduce this to fewer than 10
statements.  If it's not done by the time I finish the USB work, I will
hopefully be allowed to help with this.

Harry.

On Thu, 2005-05-05 at 11:18 -0400, Aggarwal, Vikas (OFT) wrote:
> Hi,
> 
> I have added a debug-Front-end.c &  debug-Back-end.c.  Also created my
> debug.py based on  blkif.py
> 
> But my front-end still times out even after sending
> ctrl_if_register_receiver()  to domain controller during module_init.
> 
> I think I  still did not initialize my debug.py properly.  I saw VBD
> gets initialized in device_create or create_devices. Whats the
> difference in the two?
> 
> Where should I look to initialize the event channel in domain
> controller?
> 
> My virtual device in back-end collects the debug data and writes to file
> system  so I don't  want it to be initialized during boot time via some
> config file.
> 
> -vikas
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

RE: please help: initialize XEND for my debug-FE/BE.c

[Aggarwal, Vikas (OFT)]

Hi,
How can I  get my virtual-trace-device  into the SXP?
Inside the SrvDomainDir.py:SrvDomainDir::op_create   the "configstring"
has devices for vbd/vif. I did a print on configstring.

Since I did not create a file based in blkctl.py for my
virtual-trace-device so (blkctl.py)script = xroot.get_block_script()
never happens for my trace-device. Hence (XendRoot.py)
get_config_value->sxp.child_value  will never happen.

Please clarify my confusions in area of SXP initializations.  I hacked
around the above piece of code after I saw (channel.py)("
requestReceived > No device ")   in  xend-debug.log for my device type.

I am still trying to figure out time-out in my FE driver, by looking it
messages simultaneously I think "No device" is the culprit for eventual
timeout in FE driver.

-vikas




--------------------------------------------------------
This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments.  Please notify the sender immediately by reply e-mail and delete the e-mail from your system.


-----Original Message-----

From: Harry Butterworth [mailto:harry@hebutterworth.freeserve.co.uk] 
Sent: Thursday, May 05, 2005 4:37 PM
To: Aggarwal, Vikas (OFT)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] please help: initialize XEND for my
debug-FE/BE.c

To answer your questions:

I think (75% confidence) create_devices is used to create devices when a
frontend domain is started whereas device_create is used to create an
extra single device on the fly when the frontend domain is already
running.

Your frontend is probably timing out waiting to hear about interfaces
from xend.  To establish interface connections between the frontend and
backend with the current xend code you need to implement the following
basic flow:

When xend starts, it creates a controller factory for your device class.

When a frontend domain is started, the controller factory is used to
create a controller for the frontend domain.

Configured devices for your device class are attached to the controller
for the frontend domain.

Attaching the device creates the device object which in turn does a
lookup of the "backend interface" object. The backend interface object
represents the communication channel between the frontend domain and the
backend domain.  If the backend interface object does not exist it is
created at this point.  When a backend interface is created, it finds
the backend controller object for its backend domain.  If the backend
controller object does not exist it is created at this point.

Some of the drivers assume that the backend driver is already up when
the backend controller object is created and so do not listen for the
driver status up message from the backend.  I'm implementing a driver as
loadable modules so I need to use this message.

In my case, the backend driver sends a driver status up message to xend
which is handled by the backend controller object.  The backend
controller object notifies all its backend interface objects that the
backend driver is up.

When the frontend driver is initialised, it sends a driver status up
message to xend.  This is handled by the controller object. The
controller object notifies all its backend interface objects that the
frontend driver is up.

So, a backend interface object gets a driver up/down notification at
each end.  When a backend interface finds that the drivers at both its
ends are up, it can squence the establishment of the connection:

The backend interface object sends a "be create" message to the backend
to create the object representing the interface in the backend.

The backend interface object sends a "fe interface status disconnected"
message to the frontend to create the object representing the interface
in the frontend.

The frontend allocates a page for the ring interface and sends a "fe
interface connect" message to xend which is forwarded by the controller
object to the backend interface object.

xend opens an event channel between the two domains and sends a "be
connect" message to the backend passing the event channel and the
address of the page for the ring interface.

The backend responds to the be connect and the backend interface object
sends an fe interface status connected message to the frontend, passing
the event channel number.

Unloading and reloading the frontend requires that the backend stops
writing to the shared page of memory before the frontend frees it for
reuse.  In my case, the frontend sends a driver status down message,
which is handled by the controller object for the frontend. This object
notifies all the backend interface objects for that frontend which then
send be disconnect messages and wait for a response before acknowledging
back to the controller object.  The controller object waits for all
backend interfaces to complete before acknowledging the frontend driver
status down.

Unloading and reloading the backend requires that the connection is
broken and reestablished: the backend stops using the shared pages
before sending a driver status down message. The driver status down is
handled by the backend controller which notifies all the connected
backend interfaces which in turn send fe interface status disconnected
messages to their respective frontend domains.  The frontend domains
respond with fe interface connect messages, trying to reestablish a
connection.  When the back-end driver is reloaded it sends a driver
status up which is propagated to the backend interface objects which
send be create messages again and follow up with be connect messages
containing the new shared pages and fe interface status connected
messages to complete the connection.

This is just the establishment of the connection.  There are also
messages sent by the devices to create the devices in the backend after
the backend interfaces send the be create messages to create the
interfaces.

Also, this description covers the internals of xend only. The Frontend
and backend drivers must handle the messages, map the shared page,
initialise the ring interface, allocate IRQs and bind to the event
channel as appropriate.

There are a number of people working to make this simpler, in particular
Mike Wray is apparently rewriting xend and Anthony Liguori is working on
an alternative set of tools.

Also, the grant tables implementation probably means that the above
description is out of date.  I've not investigated grant tables much
yet.

I've not been following the checkins to unstable since the xen summit so
I'll have missed anything not mentioned on the mailing list or IRC.

The current overhead in terms of client code to establish an entity on
the xen inter-domain communication "bus" is currently of the order of
1000 statements (counting FE, BE and slice of xend).  A better
inter-domain communication API could reduce this to fewer than 10
statements.  If it's not done by the time I finish the USB work, I will
hopefully be allowed to help with this.

Harry.

On Thu, 2005-05-05 at 11:18 -0400, Aggarwal, Vikas (OFT) wrote:
> Hi,
> 
> I have added a debug-Front-end.c &  debug-Back-end.c.  Also created my
> debug.py based on  blkif.py
> 
> But my front-end still times out even after sending
> ctrl_if_register_receiver()  to domain controller during module_init.
> 
> I think I  still did not initialize my debug.py properly.  I saw VBD
> gets initialized in device_create or create_devices. Whats the
> difference in the two?
> 
> Where should I look to initialize the event channel in domain
> controller?
> 
> My virtual device in back-end collects the debug data and writes to
file
> system  so I don't  want it to be initialized during boot time via
some
> config file.
> 
> -vikas
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

RE: please help: initialize XEND for my debug-FE/BE.c

[Harry Butterworth]

You need to modify tools/python/xm/create.py to get your config
parameters into the config SXP.

You'll need to have a new controllerfactory for your device class as
described in my previous note attached below.

You need to create your controllerfactory in
tools/python/xen/xend/server/SrvDaemon.py.

You also need to modify python/xen/xend/XendDomainInfo.py to add a
device handler for your device. The device handler is used to parse the
device config in the config SXP and create the devices using your new
controller factory.

You need to list your messages in 
tools/python/xen/xend/server/messages.py.

You need to do the C->python and python->c translation of your messages
in tools/python/xen/lowlevel/xu/xu.c

Harry.

On Thu, 2005-05-12 at 13:47 -0400, Aggarwal, Vikas (OFT) wrote:
> Hi,
> How can I  get my virtual-trace-device  into the SXP?
> Inside the SrvDomainDir.py:SrvDomainDir::op_create   the "configstring"
> has devices for vbd/vif. I did a print on configstring.
> 
> Since I did not create a file based in blkctl.py for my
> virtual-trace-device so (blkctl.py)script = xroot.get_block_script()
> never happens for my trace-device. Hence (XendRoot.py)
> get_config_value->sxp.child_value  will never happen.
> 
> Please clarify my confusions in area of SXP initializations.  I hacked
> around the above piece of code after I saw (channel.py)("
> requestReceived > No device ")   in  xend-debug.log for my device type.
> 
> I am still trying to figure out time-out in my FE driver, by looking it
> messages simultaneously I think "No device" is the culprit for eventual
> timeout in FE driver.
> 
> -vikas
> 
> 
> 
> 
> --------------------------------------------------------
> This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments.  Please notify the sender immediately by reply e-mail and delete the e-mail from your system.
> 
> 
> -----Original Message-----
> 
> From: Harry Butterworth [mailto:harry@hebutterworth.freeserve.co.uk] 
> Sent: Thursday, May 05, 2005 4:37 PM
> To: Aggarwal, Vikas (OFT)
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] please help: initialize XEND for my
> debug-FE/BE.c
> 
> To answer your questions:
> 
> I think (75% confidence) create_devices is used to create devices when a
> frontend domain is started whereas device_create is used to create an
> extra single device on the fly when the frontend domain is already
> running.
> 
> Your frontend is probably timing out waiting to hear about interfaces
> from xend.  To establish interface connections between the frontend and
> backend with the current xend code you need to implement the following
> basic flow:
> 
> When xend starts, it creates a controller factory for your device class.
> 
> When a frontend domain is started, the controller factory is used to
> create a controller for the frontend domain.
> 
> Configured devices for your device class are attached to the controller
> for the frontend domain.
> 
> Attaching the device creates the device object which in turn does a
> lookup of the "backend interface" object. The backend interface object
> represents the communication channel between the frontend domain and the
> backend domain.  If the backend interface object does not exist it is
> created at this point.  When a backend interface is created, it finds
> the backend controller object for its backend domain.  If the backend
> controller object does not exist it is created at this point.
> 
> Some of the drivers assume that the backend driver is already up when
> the backend controller object is created and so do not listen for the
> driver status up message from the backend.  I'm implementing a driver as
> loadable modules so I need to use this message.
> 
> In my case, the backend driver sends a driver status up message to xend
> which is handled by the backend controller object.  The backend
> controller object notifies all its backend interface objects that the
> backend driver is up.
> 
> When the frontend driver is initialised, it sends a driver status up
> message to xend.  This is handled by the controller object. The
> controller object notifies all its backend interface objects that the
> frontend driver is up.
> 
> So, a backend interface object gets a driver up/down notification at
> each end.  When a backend interface finds that the drivers at both its
> ends are up, it can squence the establishment of the connection:
> 
> The backend interface object sends a "be create" message to the backend
> to create the object representing the interface in the backend.
> 
> The backend interface object sends a "fe interface status disconnected"
> message to the frontend to create the object representing the interface
> in the frontend.
> 
> The frontend allocates a page for the ring interface and sends a "fe
> interface connect" message to xend which is forwarded by the controller
> object to the backend interface object.
> 
> xend opens an event channel between the two domains and sends a "be
> connect" message to the backend passing the event channel and the
> address of the page for the ring interface.
> 
> The backend responds to the be connect and the backend interface object
> sends an fe interface status connected message to the frontend, passing
> the event channel number.
> 
> Unloading and reloading the frontend requires that the backend stops
> writing to the shared page of memory before the frontend frees it for
> reuse.  In my case, the frontend sends a driver status down message,
> which is handled by the controller object for the frontend. This object
> notifies all the backend interface objects for that frontend which then
> send be disconnect messages and wait for a response before acknowledging
> back to the controller object.  The controller object waits for all
> backend interfaces to complete before acknowledging the frontend driver
> status down.
> 
> Unloading and reloading the backend requires that the connection is
> broken and reestablished: the backend stops using the shared pages
> before sending a driver status down message. The driver status down is
> handled by the backend controller which notifies all the connected
> backend interfaces which in turn send fe interface status disconnected
> messages to their respective frontend domains.  The frontend domains
> respond with fe interface connect messages, trying to reestablish a
> connection.  When the back-end driver is reloaded it sends a driver
> status up which is propagated to the backend interface objects which
> send be create messages again and follow up with be connect messages
> containing the new shared pages and fe interface status connected
> messages to complete the connection.
> 
> This is just the establishment of the connection.  There are also
> messages sent by the devices to create the devices in the backend after
> the backend interfaces send the be create messages to create the
> interfaces.
> 
> Also, this description covers the internals of xend only. The Frontend
> and backend drivers must handle the messages, map the shared page,
> initialise the ring interface, allocate IRQs and bind to the event
> channel as appropriate.
> 
> There are a number of people working to make this simpler, in particular
> Mike Wray is apparently rewriting xend and Anthony Liguori is working on
> an alternative set of tools.
> 
> Also, the grant tables implementation probably means that the above
> description is out of date.  I've not investigated grant tables much
> yet.
> 
> I've not been following the checkins to unstable since the xen summit so
> I'll have missed anything not mentioned on the mailing list or IRC.
> 
> The current overhead in terms of client code to establish an entity on
> the xen inter-domain communication "bus" is currently of the order of
> 1000 statements (counting FE, BE and slice of xend).  A better
> inter-domain communication API could reduce this to fewer than 10
> statements.  If it's not done by the time I finish the USB work, I will
> hopefully be allowed to help with this.
> 
> Harry.
> 
> On Thu, 2005-05-05 at 11:18 -0400, Aggarwal, Vikas (OFT) wrote:
> > Hi,
> > 
> > I have added a debug-Front-end.c &  debug-Back-end.c.  Also created my
> > debug.py based on  blkif.py
> > 
> > But my front-end still times out even after sending
> > ctrl_if_register_receiver()  to domain controller during module_init.
> > 
> > I think I  still did not initialize my debug.py properly.  I saw VBD
> > gets initialized in device_create or create_devices. Whats the
> > difference in the two?
> > 
> > Where should I look to initialize the event channel in domain
> > controller?
> > 
> > My virtual device in back-end collects the debug data and writes to
> file
> > system  so I don't  want it to be initialized during boot time via
> some
> > config file.
> > 
> > -vikas
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
>