From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Date: Fri, 18 Aug 2017 08:12:51 -0600 From: Alex Williamson To: Jan Glauber Subject: Re: [PATCH v2 3/3] vfio/pci: Don't probe devices that can't be reset Message-ID: <20170818081251.2bbffe56@w520.home> In-Reply-To: <20170818134231.GA3464@hc> References: <1502957663-5527-1-git-send-email-jglauber@cavium.com> <1502957663-5527-4-git-send-email-jglauber@cavium.com> <20170817070017.1e9c9456@w520.home> <20170818134231.GA3464@hc> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, david.daney@cavium.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Robert Richter , Jon Masters , Bjorn Helgaas , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+bjorn=helgaas.com@lists.infradead.org List-ID: On Fri, 18 Aug 2017 15:42:31 +0200 Jan Glauber wrote: > On Thu, Aug 17, 2017 at 07:00:17AM -0600, Alex Williamson wrote: > > On Thu, 17 Aug 2017 10:14:23 +0200 > > Jan Glauber wrote: > > > > > If a PCI device supports neither function-level reset, nor slot > > > or bus reset then refuse to probe it. A line is printed to inform > > > the user. > > > > But that's not what this does, this requires that the device is on a > > reset-able bus. This is a massive regression. With this we could no > > longer assign devices on the root complex or any device which doesn't > > return from bus reset and currently makes use of the NO_BUS_RESET flag > > and works happily otherwise. Full NAK. Thanks, > > Looks like I missed the slot reset check. So how about this: > > if (pci_probe_reset_slot(pdev->slot) && pci_probe_reset_bus(pdev->bus)) { > dev_warn(...); > return -ENODEV; > } > > Or am I still missing something here? We don't require that a device is on a reset-able bus/slot, so any attempt to impose that requirement means that there are devices that might work perfectly fine that are now excluded from assignment. The entire premise is unacceptable. Thanks, Alex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: alex.williamson@redhat.com (Alex Williamson) Date: Fri, 18 Aug 2017 08:12:51 -0600 Subject: [PATCH v2 3/3] vfio/pci: Don't probe devices that can't be reset In-Reply-To: <20170818134231.GA3464@hc> References: <1502957663-5527-1-git-send-email-jglauber@cavium.com> <1502957663-5527-4-git-send-email-jglauber@cavium.com> <20170817070017.1e9c9456@w520.home> <20170818134231.GA3464@hc> Message-ID: <20170818081251.2bbffe56@w520.home> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, 18 Aug 2017 15:42:31 +0200 Jan Glauber wrote: > On Thu, Aug 17, 2017 at 07:00:17AM -0600, Alex Williamson wrote: > > On Thu, 17 Aug 2017 10:14:23 +0200 > > Jan Glauber wrote: > > > > > If a PCI device supports neither function-level reset, nor slot > > > or bus reset then refuse to probe it. A line is printed to inform > > > the user. > > > > But that's not what this does, this requires that the device is on a > > reset-able bus. This is a massive regression. With this we could no > > longer assign devices on the root complex or any device which doesn't > > return from bus reset and currently makes use of the NO_BUS_RESET flag > > and works happily otherwise. Full NAK. Thanks, > > Looks like I missed the slot reset check. So how about this: > > if (pci_probe_reset_slot(pdev->slot) && pci_probe_reset_bus(pdev->bus)) { > dev_warn(...); > return -ENODEV; > } > > Or am I still missing something here? We don't require that a device is on a reset-able bus/slot, so any attempt to impose that requirement means that there are devices that might work perfectly fine that are now excluded from assignment. The entire premise is unacceptable. Thanks, Alex From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH v2 3/3] vfio/pci: Don't probe devices that can't be reset Date: Fri, 18 Aug 2017 08:12:51 -0600 Message-ID: <20170818081251.2bbffe56@w520.home> References: <1502957663-5527-1-git-send-email-jglauber@cavium.com> <1502957663-5527-4-git-send-email-jglauber@cavium.com> <20170817070017.1e9c9456@w520.home> <20170818134231.GA3464@hc> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Bjorn Helgaas , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, david.daney@cavium.com, Jon Masters , Robert Richter , linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org To: Jan Glauber Return-path: In-Reply-To: <20170818134231.GA3464@hc> Sender: linux-pci-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Fri, 18 Aug 2017 15:42:31 +0200 Jan Glauber wrote: > On Thu, Aug 17, 2017 at 07:00:17AM -0600, Alex Williamson wrote: > > On Thu, 17 Aug 2017 10:14:23 +0200 > > Jan Glauber wrote: > > > > > If a PCI device supports neither function-level reset, nor slot > > > or bus reset then refuse to probe it. A line is printed to inform > > > the user. > > > > But that's not what this does, this requires that the device is on a > > reset-able bus. This is a massive regression. With this we could no > > longer assign devices on the root complex or any device which doesn't > > return from bus reset and currently makes use of the NO_BUS_RESET flag > > and works happily otherwise. Full NAK. Thanks, > > Looks like I missed the slot reset check. So how about this: > > if (pci_probe_reset_slot(pdev->slot) && pci_probe_reset_bus(pdev->bus)) { > dev_warn(...); > return -ENODEV; > } > > Or am I still missing something here? We don't require that a device is on a reset-able bus/slot, so any attempt to impose that requirement means that there are devices that might work perfectly fine that are now excluded from assignment. The entire premise is unacceptable. Thanks, Alex