[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2])
On Fri, 15 Apr 2005, Anthony Liguori wrote: > Adam Heath wrote: > > >Er, no. The blkback allocates it's own id, which is passed around between > >them. > > > >The blkback them maps the id into a handle structure, which then has a void > >*data(or a union, if you want) that maintains a pointer to a filename, or > >reference to a block device, then a function dispatch table that knows how to > >handle the requests. > > > > > Are you suggesting this is how it should work? > > In xen-unstable, the control tools communicate through a ring-queue (a > fixed length queue with a maximum message size of 60) to the device > backends and frontends. They do not map any memory (besides the ring > queue). > > The virtual block device creation process looks something like this: > > 1) control tools send a create message through the ring queue to the backend > 2) for each virtual block device, control tools send a > BLKIF_BE_VBD_CREATE message to the backend > > This message is fixed length (see > /usr/include/xen/io/domain_controller.h--blkif_be_vbd_create_t) and has > two fields for the backend device number (pdevice) and the frontend > device number (vdevice). > > When the frontend boots up, it sends the control tools a series of > messages. One of those message contains a share memory handle which the > controls then pass to the backend. The backend maps this memory address > and the frontend and backend use this memory area to do the actual > operations of the block device. > > The control tools can only communicate with the backend (right now) via > the ring queue. You can't assume that the tools are in the same domain > as the backend (so you can't just do an ioctl or something to the kernel). > > If you wanted to support passing files, you would have to extend the > blkif_be_vbd_create_t structure to communicate a filename. This is the > problem. I hope you aren't thinking I'm suggesting having domU be able to request access to any arbitrary file; I'm suggesting that dom0 configure the mapping. Read my other mail. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |