[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

      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

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. :-)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.