Re: [Xen-devel] [RFC] Virtual disk configuration, PV vs. emulated, backward compatibility etc

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Tue, Jul 27, 2010 at 04:58:10PM +0100, Ian Campbell wrote:
> Currently the configuration syntax available in a domain configuration
> has several ways of specifying devices, some of which have slightly
> unexpected semantics wrt whether or not an emulated device is created,
> what the major number in xenstore is etc. Some also expose details of
> the guest OS's choice of major number (or rather exposes Linux's choice
> to all guests AFAICT).
> 
> In an attempt to clean this up, or at least make the strange behaviour
> more explicit, I'd like to propose some extensions to the dXpY syntax
> supported by libxl such that the other existing ways of specifying
> devices become syntactic sugar for specific well defined configurations
> in the new syntax, whilst preserving backwards compatibility.
> 
> I hope that the following will also form the basis for a future document
> (gasp!) describing the available syntax, which combinations are valid
> etc (unless someone can point me to an existing document I can update).
> 
> Virtual Disk Configuration
> --------------------------
> 
> A virtual disk is defined in the guest configuration file as d<X>p<Y>
> where <X> is the disk number and <Y> is the partition number. In
> addition a number of options can be specified.
> 
> p0 indicates the entire disk.
> 
> Device number encoding in xenstore
> ----------------------------------
> 
> Given a disk specified as dXpY the device encoding used in xenstore has
> two potential formats, legacy and extended. Both of these are already
> defined and implemented in guest frontend drivers.
> 
> The extended encoding is generally preferred but for backwards
> compatibility the legacy format must still be supported.
> 
> The legacy encoding is (major and minor 8 bits each):
>         (major << 8) | minor
> 
> The extended encoding is (disk == 19 bits, partition == 256 bits):
>         (1 << 28) | (disk << 8) | partition
> 
> Note that the extended encoding for d0p0..d0p255 overlaps in the minor
> number space with the legacy encodings of d0p0..d15p15 and therefore
> these must not be used simultaneously.
> 
> Configuration Options
> ---------------------
> 
> Each disk dXpY can optionally be followed by one or more of the
> following key value pairs (precise syntax TBD, but comma separated is
> common in similar situations).
> 
> Option keys and values with a _ prefix are for internal use only and are
> used only to provide legacy semantics for syntactic sugar and must not
> otherwise be used.
>         
>         pv = true | false
>         
>                 Should a PV backend/frontend pair be created in xenstore
>                 to correspond to this device.
>                 
>                 Default: true for HVM guests, ignored for PV guests
>                 (treated as true)
>         
>         extended = true | false
>         
>                 Request use of extended device encoding in xenstore.
>                 
>                 extended = false is only valid for d0..d15 (as d16+
>                 cannot be represented in the legacy encoding)
>                 
>                 When extended = false and in the absence of a specific
>                 _vdevice configuration option (see below) the encoding
>                 will use major==202 and minor=="(disk << 4) |
>                 partition".
>                 
>                 Default: false for d0p0..d0p255, false if _vdevice
>                 option present (see below), otherwise true.
>         
>         emul = none | ide[01].[01] | _ide[01].[01] | ...
>         
>                 none = No emulated device to be created.
>                 
>                 ide[01].[01] = Emulate IDE device. First [01] =>
>                 primary, secondary. Second [01] => master, slave
>                 
>                 _ide[01].[01] = As per ide[01].[01] however emulation is
>                 enabled iff no other disk is explicitly configured with
>                 emulation.
>                 
>                 In the future sata<X>.<Y> or similar might be added
>                 here.
>                 
>                 Default: none HVM guests, ignored for PV guests (treated
>                 as none)
>                 
>         _vdevice = <N>:<M> | <Q>
>         
>                 Enforce use of legacy device encoding in xenstore with
>                 the given major:minor or explicit value.
>                 
>                 Default: unset, encoding determined by "extended" option
>                 (see above)
> 
> Backward compatible disk configuration
> --------------------------------------
> 
> Given the above configuration options several short hands are defined
> for backwards compatibility with existing configuration files and
> guests.
> 
> These will be implemented by a straight textual substitution before
> parsing the configuration.
> 
>         hda => d0p0,pv=true,emul=ide0.0,_vdevice=3:0
>         hdb => d1p0,pv=true,emul=ide0.1,_vdevice=3:64
>         hdc => d2p0,pv=true,emul=ide1.0,_vdevice=22:0
>         hdd => d3p0,pv=true,emul=ide1.1,_vdevice=22:64
> 
>         xvda => d0p0,pv=true,emul=_ide0.0,_vdevice=202:0
>         xvdb => d1p0,pv=true,emul=_ide0.1,_vdevice=202:16
>         xvdc => d2p0,pv=true,emul=_ide1.0,_vdevice=202:32
>         xvdd => d3p0,pv=true,emul=_ide1.1,_vdevice=202:64
>         xvde => d4p0,pv=true,emul=none,_vdevice=202:80
>         ...
>         xvdo => d15p0,pv=true,emul=none,_vdevice=202:240
>         xvdp => d16p0,pv=true,emul=none
>         ...
>         xvdz => d25,pv=true,emul=none
>         
>         xvda[1..15] =>
>         d0p[1..15],pv=true,emul=_ide0.0,_vdevice=202:[0..15]
>         xvdb[1..15] => etc
> 
> Note that all the above are Linux (guest) specific.
> 
> The sd* syntax is not covered. It's unclear if this is used in the wild
> or what the existing semantics of emul= are for SCSI devices. If someone
> cares to investigate the existing behaviour then it can be added.
>

sd* devices are still often used for Xen PV domUs..
(yeah, people should use xvd*, but many people still have sd*).

-- Pasi
 


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