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

[Jim Fehlig <jfehlig@suse.com>]

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@suse.com
>>> <mailto:cyliu@suse.com>> 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.

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

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

Jim