|
|
|
|
|
|
|
|
|
|
xen-devel
Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1
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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), (continued)
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Andrew Warfield
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Anthony Liguori
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Adam Heath
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Mark Williamson
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Adam Heath
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Mark Williamson
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Anthony Liguori
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Anthony Liguori
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]),
Adam Heath <=
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Anthony Liguori
Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Philip R Auld
|
|
|
|
|