| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] libxl: virtio-blk-pci support for FV domain
On Sun, 8 May 2011, Takeshi HASEGAWA wrote:
> My patch threats virtio block devices with same manner with xvd, sd, and hd.
> Though, I need to discuss with xen developpers whether the vbd number
> assignment is reasonable or not.
>
> I guess blktap and blkback will never handle virto block device, so assigning
> (reserving) the whole range of 2 << 28 for virtio block vbd may be more
> better.
>
> Actually virtio is not Xen's VBD, so vbd number is not mandatory to work.
> However, I believe this approach makes virtio block manageable
> in same way as xvd and others.
>
Like you say virtio is not a Xen VBD protocol so I don't think we should
add a new Xen VBD encoding.
After all we don't want any Xen VBD setup for a given virtio disk.
The user should be able to specify a virtio disk using the following
syntax:
disk = ['file:/path/to/file.raw,vd0,w']
xl should parse the syntax and allocate the corresponding
libxl_device_disk struct, with vdev = "vd0".
The problem is that we need to specify a disk backend and none of the
existing disk backends are appropriate, because they are Xen VBD disk
backends while this is a completely different backend altogether.
So I would add a new libxl_disk_backend called "NONE" that means "No Xen
VBD disk backend".
So we have a libxl_device_disk with vdev = "vd0" and backend = NONE.
Eventually libxl_device_disk_add gets called with that libxl_device_disk
as parameter; validate_virtual_disk should correctly validate the disk.
After that libxl_device_disk_add calls libxl__device_disk_dev_number
that translates the vdev into a Xen VBD devid: in this case
libxl__device_disk_dev_number should return a new error that means "No
Xen VBD for this device". libxl_device_disk_add should catch the error
and return because there is nothing to do.
At this point there are still two problems to solve:
- how to handle disk hotplug
we need to add QMP support to libxl so that libxl_device_disk_add can
use it to ask qemu to dynamically allocate a new virtio disk;
- how to handle virtio for pure PV guests
in this case virtio is going to be setup through xenstore so we actually
need to write something there. But the virtio-on-xenstore protocol
doesn't exist yet so we don't really know what is going to be written
there and by whom.
This is what I would do today to add virtio-blk support to libxl,
however IanJ intends to rewrite the disk handling API in libxl so
something might end up to be very different.
Ian, do you have any comments on this?
Considering that I wouldn't want to stall the virtio-blk on xen work and
that the patch will be rather small anyway, would you be OK with
accepting a virtio-blk patch for libxl before your refactoring?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home