Re: [Xen-devel] Re: [PATCH] libxl: virtio-blk-pci support for FV domain

[Takeshi HASEGAWA <hasegaw@xxxxxxxxx>]

Thanks for the suggestions, Stefano's looks ideal and finally
it should be.

I think the change is not so urgent and afford to revise, at least while virtio ring is not working due to the issue I posted separately.

Thanks,
Takeshi

2011/5/9 Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>:
> 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?
>

--
Takeshi HASEGAWA <hasegaw@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel