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"):
> Ian Jackson (Ian.Jackson@xxxxxxxxxxxxx) wrote:
> > Daniel's solution still doesn't work for partitions >15.  Perhaps,
> 
> I think that's OK, and effectively a hard limitation w.r.t. lanana:

No, because not all guests are Linux, and anyway that limitation in
Linux may be improved in the future.  If we're going to invent a new
scheme then we may as well solve the problem properly.

> > 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
> 
> Well, we don't actually need 202, or any minor numbers at all.  The major
> is only needed for the case where xvd masquerades as IDE or SCSI.

I think you're really missing the point.  At the moment the Xen domain
config specifies whether the device is supposed to show up in the
guest as a native xvd, or masquerading as scsi or ide.  This
information is encoded, along with the disk number and partition
number, into the xenstore path.

The xenstore path element is currently as a decimal integer, and that
integer supplies this information in a encoding derived from that used
internally by pre-32-bit-devt Linux guests.  That's completely mad.
However, we can't really change it now at least for disks which fit
into the old encoding scheme, because any new scheme won't be
supported by old guests.

For disks and partitions which are out of the range which fit into the
current encodings, we need a new encoding anyway.  Old guests
definitely can't cope with those so we don't need to be compatible.

Daniel Berrange's suggestion amounts to this: rather than invent a
wholly new location in xenstore for these disks, we simply make use of
more of the available values of this integer.

I'm pointing out that when we do that we ought to take into account
our future requirements in general, which may include >15 partitions.


Something like this:

 Old format:

  202 << 8 | disk << 4 | partition      xvd, disks and partitions up to 15
    8 << 8 | disk << 4 | partition      sd, disks and partitions up to 15
    3 << 8 | disk << 6 | partition      hd, disks 0..3, partitions 1..63

 New format:

  1 << 28 | disk << 8 | partition       xvd, disks or partitions 16 onwards

 Reserved for future use:

  2 << 28 onwards


Ian.

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