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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jan 18, 2017 at 10:51:50AM +0000, Paul Durrant wrote:
> > -----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.
>  

That would be appreciated.

> > >
> > > 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?
> 

Fine by me. Let's wait a bit for other people to comment.


> > > 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?
> 

The unplug functionality, as I understand, is crucial to data integrity.
Documenting this as shortcoming doesn't seem to be good enough.  Do we
need to wait until QEMU is ready before we can apply this patch?

Wei.


>   Paul

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