[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen disk spec and emulation
> -----Original Message----- > From: Paul Durrant > Sent: 27 March 2019 13:54 > To: xen-devel (xen-devel@xxxxxxxxxxxxxxxxxxxx) > <xen-devel@xxxxxxxxxxxxxxxxxxxx> > Subject: 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. Actually I'll correct myself... d*p* also results in IDE emulation and so is equivalent to xvd. Thus in my proposal below a missing 'emu' parameter needs to imply 'emu=ide'. Paul > 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 |