Re: [Xen-devel] Greater than 16 xvd devices for blkfront

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Chris Wright writes ("Re: [Xen-devel] Greater than 16 xvd devices for 
blkfront"):
> * Daniel P. Berrange (berrange@xxxxxxxxxx) wrote:
> > +   default:
> > +           if (major > 202) {
> > +                   minor += (16 * 16 * (major - 202));
> > +                   major = 202;
> > +           }
> > +   }

The root cause of the problem is the incorporation of the Linux device
numbering scheme into the xenstore protocol, which is wrong I think.
What Daniel's excellent if rather unpleasant suggestion is doing is to
regard the xenstore number not as a `Linux device number' but rather
as a crazy encoding of the disk number.

I think this is fine but it would be good if we could think about what
the new crazy encoding is, and document it.  I infer that in Daniel's
suggestion it's:

  xenstore number = (202 << 8) + (actual disk number << 4)
                        | partition number

where the actual disk number starts at 0 for xvda and partition
numbers are 0 for whole disk or 1..15.

Daniel's solution still doesn't work for partitions >15.  Perhaps,
given that old guests are going to break anyway, we should consider a
different scheme ?  Since disks and partitions not supported by the
old encoding won't work on old guests anyway, we can use a completely
new encoding for that case provided only that it doesn't use numbers
of the form  (202 << 8) | something

Presumably we can safely use at least 31 bits.  If we reserve one to
indicate that this is the new encoding that leaves us with 30 which
should be enough for a reasonable number of disks with many
partitions each.

> I didn't think of handling overflow (since the major for scsi/ide/etc
> were involved, I expected that to fail).  But, aside of crashing an
> older guest with > 16 disks (not ideal, but I think it's possible
> already with 0x format), seems good.

If a guest takes the xenstore number to be the concatenation of its
own major and minor numbers then obviously it is leaving itself open
to breaking in the future.  dom0 admins will just have to Not Do That
Then.  (It's a shame, if true, that the guests don't have actual error
checking.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel