Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754043AbdLDQQ6 (ORCPT ); Mon, 4 Dec 2017 11:16:58 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:18240 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753010AbdLDQQw (ORCPT ); Mon, 4 Dec 2017 11:16:52 -0500 Subject: Re: [Xen-devel] [PATCH V2] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute To: Jan Beulich Cc: Juergen Gross , xen-devel@lists.xenproject.org, boris.ostrovsky@Oracle.COM, linux-kernel@vger.kernel.org, roger.pau@citrix.com References: <20171108230654.2981-1-Govinda.Tatti@Oracle.COM> <5A0424B7020000780018D6FA@prv-mh.provo.novell.com> <5A1EE54D020000780019335F@prv-mh.provo.novell.com> <2783ea8a-3ef3-c4dd-a592-52cf8e188ad4@oracle.com> <5A1FCF150200007800193632@prv-mh.provo.novell.com> <71644190-6e18-94a4-4da5-e65c041fb45a@oracle.com> <5A2027F00200007800193936@prv-mh.provo.novell.com> <5151c992-b4d8-7cf6-8ec6-cd8b621d6902@oracle.com> From: Govinda Tatti Organization: Oracle Corporation Message-ID: <3f240272-82a0-7d4e-df9c-1c4c590dfd1b@Oracle.COM> Date: Mon, 4 Dec 2017 10:16:31 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5151c992-b4d8-7cf6-8ec6-cd8b621d6902@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2429 Lines: 53 Jan, Do you have any further comments on the current version of this patch?. Otherwise, I will work on the review comments and publish next version of this patch later this week. Please let me know. Thanks. Cheers GOVINDA On 12/1/2017 10:16 AM, Govinda Tatti wrote: > > On 11/30/2017 8:46 AM, Jan Beulich wrote: >>>>> On 30.11.17 at 15:15, wrote: >>> On 11/30/2017 2:27 AM, Jan Beulich wrote: >>>>>>> On 29.11.17 at 18:38, wrote: >>>>>>> In the case of bus or slot reset, our goal is to reset connected >>>>>>> PCIe >>>>>>> fabric/card/endpoint. >>>>>>> The connected card/endpoint can be multi-function device. So, same >>>>>>> walk-through and checking >>>>>>> is needed irrespective of type of reset being used. >>>>>> I don't follow: The scope of other devices/functions possibly >>>>>> affected by a reset depends on the type of reset, doesn't it? >>>>> For PCIe platforms, both slot and bus reset endup resetting all >>>>> connected >>>>> device/functions on thesecondary bus (behind the root-port or >>>>> downstream-port). >>>> According to my understanding this contradicts the comment >>>> ahead of pci_reset_slot(), which talks of multiple slots per bus. >>>> In such a setup, I can't see why resetting on slot would affect >>>> other slots on the same bus. At the same time the comment >>>> says that the slot reset may resolve to a bus one when there's >>>> just a single slot on the bus. >>> For legacy PCI/PCI-X, we can have multiple slots per bus but not with >>> PCI-Express >>> (each link will be on a separate bus). >> Is that true even for root complex integrated end points? A >> random system's lspci output doesn't seem to agree with what >> you say. A typical example would be USB controllers all sitting >> on bus 0, but having different slot numbers. You clearly won't >> be able to ever bus-reset these, and if you checked all devices >> on bus 0 you would then also not be able to slot-reset them. > Here, slot reset refers to any PCIe slot that implements or supports > hotplug feature. The slot reset ultimately invokes "pciehp_reset_slot()". > W.r.t integrated endpoints, these can be reset either through FLR or > secondary bus reset methods only. > > Cheers > GOVINDA > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel