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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, May 05, 2005 4:37 PM
To: Aggarwal, Vikas (OFT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home