[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] xen disk spec and emulation



Hi,

  Currently, when specifying a virtual disk, the only way to determine the 
emulation model used is by selecting a particular 'vdev' numbering scheme as 
detailed in xl-disk-configuration in the docs. That document refers the reader 
to xen-vbd-interface which says:

xvd* -> xen virtual disk (from which one infers PV-only)
hd* -> IDE emulation
sd* -> SCSI emulation
d*p* -> unknown emulation

  The first choice actually results in IDE emulation, which is not stated 
anywhere AFAIK, and the fourth choice actually results in no emulation, 
although that's not stated either. These two things can, of course, be fixed in 
the documentation but I also think that the behaviour of vdev=xvd* is 
surprising and wrong. But there is another problem...

  Modern OS typically expect to use an NVMe device and we have no way to 
specify this kind of emulation. The obvious choice might be yet another vdev 
naming scheme, but this has a problem. The vdev name also dictates the vbd 
encoding (i.e. enumeration schemed used for PV devices), which seems to have 
little to do with the emulation model chosen. Adding a new encoding would also 
mean having to modify all PV frontends in existence to recognise it.

  My proposal to start to dig us out of this mess, is to add a new parameter 
for disks: emu=<model> where model would be 'ide', 'scsi', 'ahci' (for which we 
already have half-hearted and completely undocumented support), 'nvme', or 
'none'. To maintain compatibility with existing brokenness, I proposed that 
this parameter only apples if diskspec is of the d*p* form and that we document 
all other forms as deprecated. I'm fairly sure that all existent PV frontends 
recognise xen virtual disk vbd encoding so I don't believe it would be 
necessary, for instance, for 'vdev=d0p0,emu=ide' to force hd encoding and so I 
think we should also consider deprecating all encodings other than xen virtual 
disk.

  Furthermore, the 'hvm-emulated-unplug' doc. specifies that emulated nvme 
devices are unplugged differently (using code 3) from IDE or SCSI (using code 
0). I propose this also be changed so that code 0 unplugs all emulated disks 
(similarly to how 1 unplugs all emulated NICs). The unplug mechanism was never 
intended (I believe) to offer any finer grained control (although code 2 is 
somewhat of an anomaly) and I am not aware of any OS/driver that uses code 3. I 
propose this change, again, because we want to avoid having to modify all PV 
frontend code, which would be the case if NVMe devices has to be separately 
unplugged using code 3.

  Thoughts?

    Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.