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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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?  Do you think that you'll need xend in SLE12 "to give 
users time to migrate"?
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?
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. :-)
 -George


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