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

[George Dunlap <george.dunlap@eu.citrix.com>]

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

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