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


Xen-devel mailing list



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