Re: [Xen-devel] [PATCH 0 of 2] pci passthrough: support "managed" pci device in xend for libvirt usage

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 21/01/13 04:50, Jim Fehlig wrote:
> George Dunlap wrote:
> > On 17/01/13 19:12, Jim Fehlig wrote:
> > > George Dunlap wrote:
> > > > On Thu, Jan 17, 2013 at 5:29 AM, <cyliu@xxxxxxxx
> > > > <mailto:cyliu@xxxxxxxx>> wrote:
> > > >
> > > >       One of our customers requests parallel pci passthrough
> > > >       functionality between xen
> > > >       (xend and libxl) and kvm, including support managed host pci
> > > >       devices. A
> > > >       "managed" pci device will be made assignable before vm start  and
> > > >       reattach to
> > > >       its original dirver after vm shut off.
> > > >
> > > >       Currently, libvirt supports "managed=yes/no" options in pci device
> > > >       definition.
> > > >       Qemu driver already supports managed pci devices, libxl driver
> > > >       will add that
> > > >       support in libvirt source code. For xend driver, since it's
> > > >       stateful, libvirt
> > > >       can't do much things because libvirt doesn't store much informtion
> > > >       and most
> > > >       work is done by calling xend directly. Even "managed" option won't
> > > >       be stored if
> > > >       xend doesn't support it. For that reason, this patch series tries
> > > >       to add code in
> > > >       xend toolstack to support managed pci devices first, then libvirt
> > > >       can call xend
> > > >       operations directly to support "managed" host pci devices.
> > > >
> > > >       Syntax for managed pci device could be:
> > > >       pci=['0000:00:1a.0,managed=1']
> > > >
> > > >       Please share your comments. Thanks!
> > > >
> > > >
> > > > The first question (before I look at the code closely) is whether we
> > > > want to accept new features into xend.  It's not being actively
> > > > maintained, and we would like to get rid of it at some point.
> > > >
> > > > Given that you seem primarily to be using libvirt, after the 4.3
> > > > release, will there be a strong reason to use xend, instead of just
> > > > using libxl?
> > > Our SLE11 enterprise product uses the legacy toolstack and I doubt we
> > > will change that until SLE12.  We need to give users time to migrate
> > > from the old toolstack as well.
> > >
> > > Chunyan first added this functionality to the libvirt libxl driver [1],
> > > since it is preferred going forward.  Unfortunately we need to provide
> > > the same functionality in the old toolstack.  We can carry this patch in
> > > our packages if needed, but upstream backports are certainly preferred
> > > over local patches.
> > So I'm hearing that one reason you want it upstream is because you
> > prefer to have a backport, rather than just having a stand-alone patch
> > in your queue.
> >
> > That's a very good general policy, but it's not necessarily a reason
> > why xen.org should take the patch.  The main reason we would take the
> > patch would be, "SuSE will use it in 4.3".
> >
> > But it's not clear that's the case -- are you planning on pulling Xen
> > 4.3 into SLE 11?
> Probably not.
>
> >    Do you think that you'll need xend in SLE12 "to give users time to
> > migrate"?
> No.
OK, so it sounds like you're not going to need this in 4.3, so we can 
leave it out of xen.org.
> > If we really are going to get rid of xend, there must be a point where
> > users are "pushed", by lack of features (or lack of existence) onto
> > the new toolstack.  Feature parity in new releases is only going to
> > delay the inevitable.
> >
> > We've tried to make that step as simple as possible, by making xl
> > compatible with xend, and by making sure key functionality has been
> > carried over.  If there are still things that will make that
> > transition hard, maybe you could point those out and we can see if we
> > can address them?
> I'm not aware of anything.  Users simply need time to migrate their
> existing tools, scripts, etc. and we didn't want to force that on them
> in a service pack.  A new version of SLE is a different matter.
Sure, and as a distro it totally makes sense to carry it as a patch 
until then.
> > Overall it seems like if we stick with straight principles, we
> > shouldn't take the patch.
> >
> > But I'm not adamant -- I'd be interested in hearing other opinions.
> >
> > The other option, of course, would be for someone / some organization
> > to commit to being the xend maintainer going forward -- which would
> > probably involve committing to porting new libxl features over to
> > xend.  I don't think that's recommended, but everyone can spend their
> > own money / engineering hours how they like. :-)
> I wouldn't recommend that either, and designating someone as the xend
> maintainer is inhumane :).
Haha -- I'm glad we agree on that. :-)

 -George

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