[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] please help: initialize XEND for my debug-FE/BE.c
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |