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

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Ian Jackson [mailto:ian.jackson@eu.citrix.com]
> Sent: 22 March 2017 17:32
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: xen-devel@lists.xenproject.org; Wei Liu <wei.liu2@citrix.com>
> 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"):
> > This is my VM:
> >
> > root@brixham:~# xenstore-ls "/libxl/3"
> > device = ""
> >  vbd = ""
> >   51712 = ""
> ...
> >    params = "qcow2:/root/winrs2-pv1.qcow2"
> 
> > No problem using xvda... still ends up as IDE primary master.
> 
> Right.  The question is more whether this confuses the guest.  I don't
> think the tools will actually mind.
> 
> I guess that was with xapi rather than libxl ?

Nope. It was libxl.

Windows PV drivers treat hd*, sd* and xvd* numbering in the same way... they just parse the disk number out and use that as the target number of the synthetic SCSI bus exposed to Windows.

> 
> > > So maybe they should reuse the hd* numbering ?
> >
> > That might be too limiting. The hd* numbering scheme doesn't stretch
> > very far.
> 
> Indeed.  sd is rather limited too.
> 
> But, you say:
> 
>       Also, current versions of SeaBIOS do not support booting from
>       NVMe devices, so the vdev should only be used for secondary drives.
> 
> So currently this is mostly useful for testing ?

Yes. Just for testing at the moment.

> 
> Normally the emulated devices are _intended_ for bootstrapping to an
> environment that can handle vbds.  Which doesn't involve having very
> many of them.
> 
> > > > 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.
> > >
> > > In terms of the "nominal disk type" discussed in
> > > xen-vbd-interface.markdown.7, I don't think these emulated devices,
> > > which get unplugged, should be have a "nomainl disk type" of "Xen
> > > virtual disk".
> >
> > Ok. I'll submit another patch to QEMU to distinguish between
> > IDE/SCSI disks and NVMe disks in the unplug protocol, come up with a
> > new PV numbering schemed and modify the Windows frontend to
> > understand it.
> 
> Before you go away and do a lot of work, perhaps we should keep
> exploring whether my concerns are actualliy justified...
> 
> Allocating a new numbering scheme might involve changing Linux guests
> too.  (I haven't experimented with what happens if one specifies a
> reserved number.)
> 

Yes, that's a point. IIRC the doc does say that guests should ignore numbers they don't understand... but who knows if this is actually the case.

Given that there's no booting from NVMe at the moment, even HVM linux will only ever see the PV device since the emulated device will be unplugged early in boot and PV drivers are 'in box' in Linux. Windows is really the concern, where PV drivers are installed after the OS has seen the emulated device and thus the PV device needs to appear with the same 'identity' as far as the storage stack is concerned. I'm pretty sure this worked when I tried it a few months back using xvd* numbering (while coming up with the QEMU patch) but I'll check again.

  Paul

> Ian.

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