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: basic support for virtio disk

To: Wei Liu <liuw@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] libxl: basic support for virtio disk
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Thu, 2 Jun 2011 16:04:43 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 02 Jun 2011 08:06:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTi=HZvj_7BqOAoiJ4cB99OZJmEoLTA@xxxxxxxxxxxxxx>
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>
References: <BANLkTikbJFnVzqhnRy0=Vb0S=pgENDZ_qw@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1105271315270.12963@kaball-desktop> <BANLkTikM4AJz1jQi2v4vwM=EP7TEfUP-YQ@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1105271559170.12963@kaball-desktop> <BANLkTikA_Gw8fgQ4K_=eEg=jkx1TDKMSwQ@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1105311232300.12963@kaball-desktop> <BANLkTimiDzJLiM++TUR1ysksRjPYjBeu2Q@xxxxxxxxxxxxxx> <19942.17843.474817.123371@xxxxxxxxxxxxxxxxxxxxxxxx> <BANLkTi=HZvj_7BqOAoiJ4cB99OZJmEoLTA@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Wed, 1 Jun 2011, Wei Liu wrote:
> On Wed, Jun 1, 2011 at 9:59 PM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> > Wei Liu writes ("[Xen-devel] Re: [PATCH] libxl: basic support for virtio 
> > disk"):
> >> Revised patch.
> >>
> >> Add code in libxl__device_disk_string_of_backend.
> >>
> >> Upper limit of virtio disk follows scsi.
> >
> > I'm not sure what you mean here.  Do you mean that Linux only supports
> > as many virtio disks as it supports scsi disks ?  Is this a
> > fundamental limitation of the virtio protocol ?
> >
> I asked about the limitation in qemu-devel, the answer is
> "virtio-blk as used by KVM is exposed as a virtio PCI adapter.  There
> is a 1:1 mapping between virtio-blk, PCI adapters, and block devices
> being presented by QEMU:
> 1 virtio-blk device in guest == 1 virtio-pci adapter in guest == 1
> block device in QEMU
> The maximum number is really limited by the PCI bus, not virtio.  In
> terms of coding, you should try not to impose a hard limit at all."
> Thus Stefano suggest I use the same limitation as SCSI disk.

The limitation on the number of partitions is meaningless for virtio and
the limitation on the number of disks in arbitrary, as it is arbitrary
the current limitation on the number of scsi disks.

> >> +                else if (strncmp(disks[i].vdev, "vd", 2) == 0)
> >> +                    drive = libxl__sprintf
> >> +                        (gc, 
> >> "file=%s,if=virtio,index=%d,media=disk,format=%s",
> >> +                         disks[i].pdev_path, disk, format);
> >
> > Maybe I'm missing something but this seems not to use the partition
> > number at all ?
> >
> Also answered in qemu-devel
> "Partitions are not at the virtio-blk level.  The guest operating
> system will see the virtio-blk disk and scan its partition table to
> determine which partitions are available.  The limit then depends on
> the partitioning scheme that you use (legacy boot record, GPT, etc)."
> So I'm not using the partition number here.
> In fact, we should not support vda1, vda2, right?
> The discussion thread is at
> http://marc.info/?l=qemu-devel&m=130689044627041&w=2

Device names like xvda1, xvda2, etc, are currently supported only with
PV guests.
There is no way to specify a single partition with HVM guests.
Considering that this patch is only meant for HVM guest, I think it is
correct to leave out the partition number.

> > The existing code seems rather broken TBH.
> >
> Hmm... I'm not catching up with libxl. Should be more careful next time...
Why should this code be broken?
It seems all right to me. Does it break something?
Xen-devel mailing list