[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

 


Rackspace

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