[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |