[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
  • From: Takeshi HASEGAWA <hasegaw@xxxxxxxxx>
  • Date: Tue, 10 May 2011 11:26:49 +0900
  • Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, Xen Devel <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Wei Liu <liuw@xxxxxxxxx>
  • Delivery-date: Mon, 09 May 2011 19:27:30 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=nGL4wlRS7JdhnkAotEo/vBvoUUpJdLIelGyK9B/xYXvNWR6EQ+coLtbe8CHLLdeCuj vkDu5RDTZoki40wst7u0ipaPKAeJ91FzCCspIAnKB3+1Ho/bshFYMUtpdwI7ZY9FVWO5 i9tjSdCCtc39dgHz9HrZIaSq8daxp5Mr6SAOk=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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.


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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.