This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] libxl: virtio-blk-pci support for FV domain
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
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=T3+HjzYAQ2cXaold3Y0u5qOx16Ss6nMP/LEobR7fRVU=; b=hXj2oURWcHXb0+EHevEtuKiTDkCI+K0QoBSN/qlr6FqkALW+i2i2DYHsXi7qQaRtDp 8hvE1qk9rA/eBJogIV+IQxzJn5VGKp4VIRr75HOEnmsCmMhSvaxlCps2b7bU7NhE/Wj2 upe5fide+wHiY2oxstOrR6zQn5z3I0152hTwk=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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
<Prev in Thread] Current Thread [Next in Thread>