Received: by 10.192.165.156 with SMTP id m28csp2043980imm; Thu, 12 Apr 2018 07:44:17 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+MkzdobZ9sDjbG9HvDndqoasTwsT/D2ydGvFggrero4GdqiyTT8vH2Xs27Dmgb2XZW9wxv X-Received: by 10.98.180.24 with SMTP id h24mr7931259pfn.213.1523544257575; Thu, 12 Apr 2018 07:44:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523544257; cv=none; d=google.com; s=arc-20160816; b=pXuROB0v7JtxMtQpLTMLmNCTWoxGTc4Pi6IUZLSxsnjjpOe+rvHLidyuPEeKn3XqEX TxZ0XvjzMz2HcwbxvBZVUjwY9rVmn+qCyJOJ3zQ2glSJWvZWMqztnIRnBoTmy0sFGrh6 t6waKy8GtRZS7QnxDnbnHE9mQEl3E5YNvFvVdnprSEwfWL+dhaCeOVPVeMJW4vJu6Li7 U7bSIyC/0UEsP/WbnORW3OXQUUNKDSw/trzVdwMNPh0xhfg795HS8ONAqYXuXdk3Eke8 CK7pRWh1GLZDNWlBaiXWWMthXzX2HpSfljTIHrgVPt4oaFjUFegMLA3S3/UxgmIpVrtf u99A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=r47sDPPGGjob9gxJJFlmqbBfhbA9dUcgRJooI1S4sGA=; b=maR/oM80dgKUoS7xUBBj8y4EoBybk1n5ORhpqo48zCjAIxRmr4LM81gumvNmBpPhMB xZ6e4JJqqFxpJdb22UJegAOP2trWkGTiZL2IAJ/SN41b2BIJ7BSU8T0Zm0Qf7S/XWMuf 82Lvxjj0HXXXBBVz3H4rSCQPaXo3TK8xPFagIBuu79bLNJQsdDf9CGZXczsli+WJmQpG bfv3L4zrwRGov3PxmlVF3r+sfRdbEOwiL9j3kVA/dSK7lj6k14KLecf+vqI353oPc/mz Y/uvYqbEtJlxUlONe94Uy5d1QYQB0zaLqKWiA5Q19YLhoDudo5DStlr0E6vcz8MvFyPA DH9g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m9-v6si3525064pll.67.2018.04.12.07.43.40; Thu, 12 Apr 2018 07:44:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753468AbeDLOjj (ORCPT + 99 others); Thu, 12 Apr 2018 10:39:39 -0400 Received: from mga11.intel.com ([192.55.52.93]:1422 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753210AbeDLOjg (ORCPT ); Thu, 12 Apr 2018 10:39:36 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2018 07:38:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,442,1517904000"; d="scan'208";a="32868832" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by orsmga007.jf.intel.com with ESMTP; 12 Apr 2018 07:38:57 -0700 Date: Thu, 12 Apr 2018 08:39:54 -0600 From: Keith Busch To: Sinan Kaya Cc: Bjorn Helgaas , Oza Pawandeep , Bjorn Helgaas , Philippe Ombredanne , Thomas Gleixner , Greg Kroah-Hartman , Kate Stewart , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Dongdong Liu , Wei Zhang , Timur Tabi , Alex Williamson Subject: Re: [PATCH v13 6/6] PCI/DPC: Do not do recovery for hotplug enabled system Message-ID: <20180412143954.GB4810@localhost.localdomain> References: <1523284914-2037-1-git-send-email-poza@codeaurora.org> <1523284914-2037-7-git-send-email-poza@codeaurora.org> <20180410210349.GG54986@bhelgaas-glaptop.roam.corp.google.com> <13efe2e8-74c8-acb4-ec58-f79b14a1f182@codeaurora.org> <20180412140648.GD145698@bhelgaas-glaptop.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 12, 2018 at 10:34:37AM -0400, Sinan Kaya wrote: > On 4/12/2018 10:06 AM, Bjorn Helgaas wrote: > > > > I think the scenario you are describing is two systems that are > > identical except that in the first, the endpoint is below a hotplug > > bridge, while in the second, it's below a non-hotplug bridge. There's > > no physical hotplug (no drive removed or inserted), and DPC is > > triggered in both systems. > > > > I suggest that DPC should be handled identically in both systems: > > > > - The PCI core should have the same view of the endpoint: it should > > be removed and re-added in both cases (or in neither case). > > > > - The endpoint itself should not be able to tell the difference: it > > should see a link down event, followed by a link retrain, followed > > by the same sequence of config accesses, etc. > > > > - The endpoint driver should not be able to tell the difference, > > i.e., we should be calling the same pci_error_handlers callbacks > > in both cases. > > > > It's true that in the non-hotplug system, pciehp probably won't start > > re-enumeration, so we might need an alternate path to trigger that. > > > > But that's not what we're doing in this patch. In this patch we're > > adding a much bigger difference: for hotplug bridges, we stop and > > remove the hierarchy below the bridge; for non-hotplug bridges, we do > > the AER-style flow of calling pci_error_handlers callbacks. > > Our approach on V12 was to go to AER style recovery for all DPC events > regardless of hotplug support or not. > > Keith was not comfortable with this approach. That's why, we special cased > hotplug. > > If we drop 6/6 on this patch on v13, we achieve this. We still have to > take care of Keith's inputs on individual patches. > > we have been struggling with the direction for a while. > > Keith, what do you think? My only concern was for existing production environments that use DPC for handling surprise removal, and I don't wish to break the existing uses.