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@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