: Expand Xen blkfront for > 16 xvd
Subsystems (3)
PATCH 1/1 : Expand Xen blkfront for > 16 xvd
Jeremy,
Until recently, the maximum number of xvd block devices you could attach to
a Xen domU was 16. This limitation turned out to be problematic for some users, so it was expanded to handle a much larger number of disks. However, this requires a couple of changes in the way that blkfront scans for disks. This functionality is already present in the Xen linux-2.6.18-xen.hg tree; the attached patch adds this functionality to the mainline xen-blkfront implementation. I successfully tested it on a 2.6.25 tree. I build tested it on 2.6.27-rc3, but couldn't get that tree to boot due to some other bug.
drivers/block/xen-blkfront.c +55 -21
@@ -105,15 +105,17 @@ static DEFINE_SPINLOCK(blkif_io_lock);#define GRANT_INVALID_REF 0#define PARTS_PER_DISK 16 +#define PARTS_PER_EXT_DISK 256#define BLKIF_MAJOR (dev) ((dev)>>8)#define BLKIF_MINOR (dev) ((dev) & 0xff) -#define DEV_NAME "xvd"/* name in /dev */ +#define EXT_SHIFT 28 +#define EXTENDED (1<<EXT_SHIFT) +#define VDEV_IS_EXTENDED (dev) ((dev)&(EXTENDED)) +#define BLKIF_MINOR_EXT (dev) ((dev)&(~EXTENDED)) -/* Information about our VBDs. */ -#define MAX_VBDS 64 -static LIST_HEAD (vbds_list); +#define DEV_NAME "xvd"/* name in /dev */ static int get_id_from_freelist (struct blkfront_info *info) {
@@ -386,31 +388,60 @@ static int xlvbd_barrier(struct blkfront_info *info) } -static int xlvbd_alloc_gendisk (int minor,blkif_sector_t capacity, -int vdevice,u16 vdisk_info,u16 sector_size, -struct blkfront_info *info) +static int xlvbd_alloc_gendisk (blkif_sector_t capacity, +struct blkfront_info *info, +u16 vdisk_info,u16 sector_size) {struct gendisk *gd;int nr_minors =1 ;int err = -ENODEV ; +unsigned int offset; +int minor; +int nr_parts;BUG_ON (info->gd !=NULL );BUG_ON (info->rq !=NULL ); -if ((minor %PARTS_PER_DISK ) ==0 ) - nr_minors =PARTS_PER_DISK ; +if ((info->vdevice>>EXT_SHIFT ) >1 ) { +/* this is above the extended range; something is wrong */ +printk (KERN_WARNING "blkfront: vdevice 0x%x is above the extended range; ignoring\n" , info->vdevice); +return -ENODEV ; + } + +if (!VDEV_IS_EXTENDED (info->vdevice)) { + minor =BLKIF_MINOR (info->vdevice); + nr_parts =PARTS_PER_DISK ; + }else { + minor =BLKIF_MINOR_EXT (info->vdevice); + nr_parts =PARTS_PER_EXT_DISK ; + } + +if ((minor % nr_parts) ==0 ) + nr_minors = nr_parts; gd =alloc_disk (nr_minors);if (gd ==NULL ) goto out; -if (nr_minors >1 ) -sprintf (gd->disk_name,"%s%c" ,DEV_NAME , -'a' + minor /PARTS_PER_DISK ); -else -sprintf (gd->disk_name,"%s%c%d" ,DEV_NAME , -'a' + minor /PARTS_PER_DISK , - minor %PARTS_PER_DISK ); + offset = minor / nr_parts; + +if (nr_minors >1 ) { +if (offset <26 ) +sprintf (gd->disk_name,"%s%c" ,DEV_NAME ,'a' + offset); +else +sprintf (gd->disk_name,"%s%c%c" ,DEV_NAME , +'a' + ((offset /26 )-1 ),'a' + (offset %26 )); + }else { +if (offset <26 ) +sprintf (gd->disk_name,"%s%c%d" ,DEV_NAME , +'a' + offset, + minor & (nr_parts -1 )); +else +sprintf (gd->disk_name,"%s%c%c%d" ,DEV_NAME , +'a' + ((offset /26 ) -1 ), +'a' + (offset %26 ), + minor & (nr_parts -1 )); + } gd->major =XENVBD_MAJOR ; gd->first_minor = minor;
@@ -699,8 +730,13 @@ static int blkfront_probe(struct xenbus_device *dev, err =xenbus_scanf (XBT_NIL , dev->nodename,"virtual-device" ,"%i" , &vdevice);if (err !=1 ) { -xenbus_dev_fatal (dev, err,"reading virtual-device" ); -return err; +/* go looking in the extended area instead */ + err =xenbus_scanf (XBT_NIL , dev->nodename,"virtual-device-ext" , +"%i" , &vdevice); +if (err !=1 ) { +xenbus_dev_fatal (dev, err,"reading virtual-device" ); +return err; + } } info =kzalloc (sizeof (*info),GFP_KERNEL );
@@ -861,9 +897,7 @@ static void blkfront_connect(struct blkfront_info *info)if (err) info->feature_barrier =0 ; - err =xlvbd_alloc_gendisk (BLKIF_MINOR (info->vdevice), - sectors, info->vdevice, - binfo, sector_size, info); + err =xlvbd_alloc_gendisk (sectors, info, binfo, sector_size);if (err) {xenbus_dev_fatal (info->xbdev, err,"xlvbd_add at %s" , info->xbdev->otherend);
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 8 lines · Chris Lalancette
Jeremy,
Until recently, the maximum number of xvd block devices you could attach to
a Xen domU was 16. This limitation turned out to be problematic for some users, so it was expanded to handle a much larger number of disks. However, this requires a couple of changes in the way that blkfront scans for disks. This functionality is already present in the Xen linux-2.6.18-xen.hg tree; the attached patch adds this functionality to the mainline xen-blkfront implementation.
I haven't tested this yet. You have tested it OK with some pvops kernel? If so, send it to Jens Axboe with my ack.
Quoted 2 lines
I successfully tested it on a 2.6.25 tree. I build tested it
on 2.6.27-rc3, but couldn't get that tree to boot due to some other bug.
What other bug?
J
Quoted 10 lines · Jeremy Fitzhardinge
Quoted 8 lines · Chris Lalancette
Jeremy,
Until recently, the maximum number of xvd block devices you could attach to
a Xen domU was 16. This limitation turned out to be problematic for some users, so it was expanded to handle a much larger number of disks. However, this requires a couple of changes in the way that blkfront scans for disks. This functionality is already present in the Xen linux-2.6.18-xen.hg tree; the attached patch adds this functionality to the mainline xen-blkfront implementation.
Quoted 2 lines
I haven't tested this yet. You have tested it OK with some pvops kernel? If so, send it to Jens Axboe with my ack.
Yes, I tested it with a 2.6.25-something Fedora 9 pv-ops kernel (i386). I'll send it along to Jens.
Quoted 5 lines
Quoted 3 lines
I successfully tested it on a 2.6.25 tree. I build tested it
on 2.6.27-rc3, but couldn't get that tree to boot due to some other bug.What other bug?
This is http://bugzilla.redhat.com/show_bug.cgi?id=459067, that I think you've already looked at. Basically any F-10 or upstream git kernel is crashing on an i386 RHEL-5 HV. We were a little confused by your comment in that bug, however; we were under the impression that the fix you mentioned was specifically a 32-on-64 fix, not for 32-on-32. If we were wrong, please point it out.
Thanks,
Chris Lalancette