From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takeshi HASEGAWA Subject: Re: Re: [PATCH] libxl: virtio-blk-pci support for FV domain Date: Tue, 10 May 2011 11:26:49 +0900 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1128429396==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: Anthony Perard , Xen Devel , Ian Jackson , Wei Liu List-Id: xen-devel@lists.xenproject.org --===============1128429396== Content-Type: multipart/alternative; boundary=001485f547242f053404a2e2b0bd --001485f547242f053404a2e2b0bd Content-Type: text/plain; charset=ISO-8859-1 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 : > 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 --001485f547242f053404a2e2b0bd Content-Type: text/html; charset=ISO-8859-1

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@eu.citrix.com>:
> 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@gmail.com>

--001485f547242f053404a2e2b0bd-- --===============1128429396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1128429396==--