This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] RE: xl fails to work with some command

To: Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RE: xl fails to work with some command
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Tue, 31 Aug 2010 11:07:27 +0100
Cc: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Weidong Han <weidong.han@xxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 31 Aug 2010 03:08:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1008311038320.18383@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <749B9D3DBF0F054390025D9EAFF47F222A060143@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <749B9D3DBF0F054390025D9EAFF47F222A060CFB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1008231102520.2545@kaball-desktop> <749B9D3DBF0F054390025D9EAFF47F222A060E65@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1008251648250.2545@kaball-desktop> <4C760542.7080003@xxxxxxxxx> <alpine.DEB.2.00.1008261311520.2545@kaball-desktop> <20100826135017.GA3792@xxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1008261646560.2545@kaball-desktop> <4C770710.1040604@xxxxxxxxx> <alpine.DEB.2.00.1008271151110.2545@kaball-desktop> <4C7CAA1C.1030902@xxxxxxxxx> <alpine.DEB.2.00.1008311038320.18383@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2010-08-31 at 10:40 +0100, Stefano Stabellini wrote:
> On Tue, 31 Aug 2010, Weidong Han wrote:
> > > As stated above, xl doesn't know how to FLR a device, the dom0 kernel
> > > provides a way to do it.
> > > XCP kernels have pciback do_flr that has all the HW specific FLR
> > > functions you are referring to AFAIK, but the pvops kernel, that uses
> > > the standard reset node, does not.
> > >
> > >   
> > So it should implement specific FLRs in pciback like XCP/XCI.
> > 
> Why should we reimplement pci FLR in pciback when the kernel has
> already a way to do it?
> I am not seeing pciback FLR going upstream easily.
> Besides if some devices need specific FLRs, shouldn't the generic kernel
> FLR function know about it?

Yes, absolutely, the correct way to fix this is to add the necessary
fixes/quirks to the upstream FLR infrastructure so that everybody
benefits, not to add stuff to pciback where a) only Xen benefits and b)
we have to maintain it forever because it cannot be upstreamed because
the correct fix is to fix it in the upstream LFR infrastructure ;-).


Xen-devel mailing list