On Wed, Jan 18, 2017 at 12:15:22PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 18 January 2017 12:02
> > To: Paul Durrant <paul.durr...@citrix.com>
> > Cc: Wei Liu <wei.l...@citrix.com>; xen-de...@lists.xenproject.org; Ian
> > Jackson <ian.jack...@citrix.com>
> > Subject: Re: [PATCH RESEND] tools/libxl: add support for emulated NVMe
> > drives
> > 
> [snip]
> > > > >
> > > > > -   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?
> 
> It will take time to get a patch into QEMU and if you're going to use
> PV drivers then you have little interest in the emulation model. I
> think just documenting it would be ok.

This is OK provided there is no safety issue. If we can't rule that out,
...

> For safety I guess I could explore the possibility of having libxl not
> create a PV backend for this vdev type.

... this is the best option for now.

Wei.

> 
>   Paul
> 
> > 
> > Wei.
> > 
> > 
> > >   Paul

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

Reply via email to