Re: [Xen-devel] [PATCH RESEND] tools/libxl: add support for emulated NVMe drives

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Jackson [mailto:ian.jackson@xxxxxxxxxxxxx]
> Sent: 22 March 2017 16:03
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu <wei.liu2@xxxxxxxxxx>
> Subject: RE: [PATCH RESEND] tools/libxl: add support for emulated NVMe
> drives
> 
> Paul Durrant writes ("RE: [PATCH RESEND] tools/libxl: add support for
> emulated NVMe drives"):
> > > Oh, wait, I have just noticed that you have reused an entry in this
> > > table!
> > >
> > >        1 << 28 | disk << 8 | partition   xvd, disks or partitions 16 
> > > onwards
> > > ...
> > > > +    1 << 28 | disk << 8               nvme, all disks, whole disk only
> >
> > Yes, that was intentional. No need for a new concrete encoding if we
> > ignore namespaces, as I said in the commit comment. If you want to
> > support namespaces then it would need something new... which doesn't
> > seem worth it since QEMU has no support.
> 
> That's not my point.  The purpose of this table is to advise guests
> what the conventional in-guest device name ought to be for a certain
> vbd.

Yes, and xvd<something> is a perfectly fine name for a PV device in pretty much 
every case. It's already the case that emulated IDE disks are exposed to guests 
using xvd* numbering.

> 
> We can't have one single numerical encoding mapping to two device
> names.  That makes no sense.
> 
> Presumably these NVME devices should be subject to the same vbd and
> unplug approach as scsi and ide disks.

Yes, that's what the QEMU patch does.

> In which case guests need to
> be told that the device name for the vbd should be "nvme<something>",
> which can only be done by using a different number.
> 

That means modifications to PV frontends would be needed, which is going to 
make things more difficult. Most OS find disks by UUID these days anyway so I'm 
still not sure that just using xvd* numbering would really be a problem.

  Paul

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel