From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 0 of 2] pci passthrough: support "managed" pci device in xend for libvirt usage Date: Mon, 21 Jan 2013 11:40:24 +0000 Message-ID: <50FD2928.9040709@eu.citrix.com> References: <50F84D01.1050900@suse.com> <50F95092.8020703@eu.citrix.com> <50FCC91A.5010106@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50FCC91A.5010106@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jim Fehlig Cc: "xen-devel@lists.xensource.com" , "Keir (Xen.org)" , Ian Campbell , Ian Jackson , "cyliu@suse.com" , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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, >>> > 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