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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> Sent: 18 January 2017 10:29
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Ian Jackson <Ian.Jackson@xxxxxxxxxx>;
> Wei Liu <wei.liu2@xxxxxxxxxx>
> Subject: Re: [PATCH RESEND] tools/libxl: add support for emulated NVMe
> drives
> 
> On Fri, Jan 13, 2017 at 02:00:41PM +0000, Paul Durrant wrote:
> > Upstream QEMU supports emulation of NVM Express a.k.a. NVMe drives.
> >
> > This patch adds a new vdev type into libxl to allow such drives to be
> > presented to HVM guests. Because the purpose of the new vdev is purely
> > to configure emulation, the syntax only supports specification of
> > whole disks. Also there is no need to introduce a new concrete VBD
> > encoding for NVMe drives.
> 
> This seems to be in contradiction with the code below?
>

No, there's no contradiction because the encoding is identical to xvdX 
encoding. Perhaps I should state that in the comment.
 
> >
> > NOTE: QEMU's emulation only supports a single NVMe namespace, so the
> >       vdev syntax does not include specification of a namespace.
> >       Also, current versions of SeaBIOS do not support booting from
> >       NVMe devices, so the vdev should only be used for secondary
> >       drives.
> >
> 
> I don't know much about NVMe, but I presume we could just extend the
> proposed syntax to support namespaces should the need arise?
> 

Well, I could make the syntax be nvme<device>n<namespace> (to match linux's 
namespace syntax) and insist that namespace be 1 at the moment. Do you think 
that would be preferable?

> > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > ---
> > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
> > ---
> >  docs/man/xen-vbd-interface.markdown.7 | 15 ++++++++-------
> >  docs/man/xl-disk-configuration.pod.5  |  4 ++--
> >  tools/libxl/libxl_device.c            |  8 ++++++++
> >  tools/libxl/libxl_dm.c                |  6 ++++++
> >  4 files changed, 24 insertions(+), 9 deletions(-)
> >
> > diff --git a/docs/man/xen-vbd-interface.markdown.7 b/docs/man/xen-
> vbd-interface.markdown.7
> > index 1c996bf..8fd378c 100644
> > --- a/docs/man/xen-vbd-interface.markdown.7
> > +++ b/docs/man/xen-vbd-interface.markdown.7
> > @@ -8,12 +8,12 @@ emulated IDE, AHCI or SCSI disks.
> >  The abstract interface involves specifying, for each block device:
> >
> >   * Nominal disk type: Xen virtual disk (aka xvd*, the default); SCSI
> > -   (sd*); IDE or AHCI (hd*).
> > +   (sd*); IDE or AHCI (hd*); NVMe.
> 
> NVMe (nvme*) ?

Yes.

> 
> >
> > -   For HVM guests, each whole-disk hd* and and sd* device is made
> > -   available _both_ via emulated IDE resp. SCSI controller, _and_ as a
> > -   Xen VBD.  The HVM guest is entitled to assume that the IDE or SCSI
> > -   disks available via the emulated IDE controller target the same
> > +   For HVM guests, each whole-disk hd*, sd* or nvme* device is made
> > +   available _both_ via emulated IDE, SCSI controller or NVMe drive
> > +   respectively _and_ as a Xen VBD.  The HVM guest is entitled to
> > +   assume that the disks available via the emulation target the same
> 
> How do you expect the guest to deal with multipath NVMe devices? Maybe
> we need to add unplug support for NVMe devices in QEMU?

That's true. For convenience, there would need to a QEMU patch for unplug to 
allow displacement of the emulated device with PV. I can document this as a 
shortcoming at the moment, if that's ok?

  Paul

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