From patchwork Wed Mar 4 17:01:59 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 5938451 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id A9B299F36A for ; Wed, 4 Mar 2015 17:02:20 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BC429202FE for ; Wed, 4 Mar 2015 17:02:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E610A202DD for ; Wed, 4 Mar 2015 17:02:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759433AbbCDRCP (ORCPT ); Wed, 4 Mar 2015 12:02:15 -0500 Received: from mail-oi0-f42.google.com ([209.85.218.42]:36024 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758277AbbCDRCO (ORCPT ); Wed, 4 Mar 2015 12:02:14 -0500 Received: by oiba3 with SMTP id a3so6764810oib.3 for ; Wed, 04 Mar 2015 09:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=BUf1LDWRzey+19v6K8FotnKJBIpSN4c1a1N3zZOOupc=; b=NIkZpQcn7lesw8sykIDA/2yEN/MdcvP6DRkiCCC9MLKWdmPdT6gtofLUI3zOCTZdM/ RR9f3DVhJoQkd5GAKWhc+XkRawM50P2eretCGTa6QGUeNQ5B7XHXR0Auo6xcgwIJBILN qkwsXOKRl8W1Es3lT9GwIx6qyYucyxAKHaLq6lrQi18TiIntbrgsVAKvL6mIXsO26o3w q0lEyIRhrhoUv2CSUZ3cQq4UnoeG5u6aqfO6E3NjNvcm1QoafP1cjYqm31uUfNj0P7pN RFYIusqOM3KZzaXQ5aYW8TvUq11P+cbVQwtOeVQ9INYE+UGfpzPVCN9PQbNgE0mYgvLO aTFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=BUf1LDWRzey+19v6K8FotnKJBIpSN4c1a1N3zZOOupc=; b=hpHwPEYWMLWeDu7rbOrfb5O7kmdbxppyOwFTspbGx+iO9a92QgwjqMicCk7E+jLfuo oI+qdSldsy/1oJMP0s7fsjyFsG7zaZVNnueyQxakVl70G8RAtKPbolgtxHhGabHQmYfA CRFgqoMgk04SaEZHFrcA65iyaPmkOOFIDAS48Zf3FrGVeRCTnabTfRYaUh0i9cq1l5yb e1IKfxcy/94tMcbArSSndZHRrgy6PtgG3z7F2M5rANQqIqgzEMynyDbj9s8zVJa4z4KZ Y8izpw4/5mkywn3EEeIrT5PGYDPKocXtkU8Mc7KU8zQvSBe2EXtEJ5lPFobdm3PT1ueh cozg== X-Gm-Message-State: ALoCoQm5xtkenjTCLS/9dCj2UAaw1p/HLEReSlBC42P4SIncdNCMmdpiOR1RgMQBxnJxSrJR/88Q X-Received: by 10.60.70.211 with SMTP id o19mr690795oeu.21.1425488533659; Wed, 04 Mar 2015 09:02:13 -0800 (PST) Received: from google.com ([69.71.1.1]) by mx.google.com with ESMTPSA id m64sm2614568oik.20.2015.03.04.09.02.10 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 04 Mar 2015 09:02:13 -0800 (PST) Date: Wed, 4 Mar 2015 11:01:59 -0600 From: Bjorn Helgaas To: Daniel J Blueman Cc: Jiang Liu , Ingo Molnar , H Peter Anvin , Thomas Gleixner , Linux Kernel , Steffen Persvold , "x86@kernel.org" , Yinghai Lu , linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: PCIe 32-bit MMIO exhaustion Message-ID: <20150304170159.GC22299@google.com> References: <54C8A10B.3070207@numascale.com> <54EC0013.7000100@numascale.com> <20150303223816.GB22299@google.com> <54F6B044.7000609@numascale.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54F6B044.7000609@numascale.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FSL_HELO_FAKE, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Mar 04, 2015 at 03:12:04PM +0800, Daniel J Blueman wrote: > Your patch solves the conflicts nicely [1] with: > > From f835b16b0758a1dde6042a0e4c8aa5a2e8be5f21 Mon Sep 17 00:00:00 2001 > From: Daniel J Blueman > Date: Wed, 4 Mar 2015 14:53:00 +0800 > Subject: [PATCH] Mark PCI BARs with address 0 as unset > > Allow the kernel to activate the unset flag for PCI BAR resources if > the firmware assigns address 0 (invalid as legacy IO is in this range). > > This allows preventing conflicts with legacy IO/ACPI PNP resources in > this range. > > Signed-off-by: Daniel J Blueman > --- > drivers/pci/probe.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index 8d2f400..ef43652 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -281,6 +281,13 @@ int __pci_read_base(struct pci_dev *dev, enum > pci_bar_type type, > pcibios_resource_to_bus(dev->bus, &inverted_region, res); > > /* > + * If firmware doesn't assign a valid PCI address (as legacy IO is below > + * PCI IO), mark resource unset to prevent later resource conflicts > + */ > + if (region.start == 0) > + res->flags |= IORESOURCE_UNSET; It's true that an uninitialized BAR should contain zero. But an initialized BAR may also contain zero, since zero is a valid PCI memory or I/O address, so I don't really want to preclude that here. On large systems with host bridges that support address translation, it would be reasonable to have something like this: pci_bus 0001:00: root bus resource [mem 0x100000000-0x1ffffffff] (bus address [0x00000000-0xffffffff]) In that case, an initialized BAR may contain zero and that should not be an error. On your system, I don't think you advertise an I/O aperture to bus 0001:00. I'd like to make the PCI core smart enough to notice that and just ignore any I/O BARs on that bus. There's an argument for doing this immediately, here inside __pci_read_base(): we could look for an upstream window that contains the BAR we're reading. I'd like to be able to do that someday, but I'm not sure we have enough of the upstream topology set up to do that. Can you try the patch below, which tries to do it a little later? > + /* > * If "A" is a BAR value (a bus address), "bus_to_resource(A)" is > * the corresponding resource address (the physical address used by > * the CPU. Converting that resource address back to a bus address > > [1] https://resource.numascale.com/dmesg-4.0.0-rc2.txt This URL doesn't work for me. Bjorn commit 66c15b678466cb217f2615d4078d12a2ee4c99ac Author: Bjorn Helgaas Date: Wed Mar 4 10:47:35 2015 -0600 PCI: Mark invalid BARs as unassigned If a BAR is not inside any upstream bridge window, or if it conflicts with another resource, mark it as IORESOURCE_UNSET so we don't try to use it. We may be able to assign a different address for it. Signed-off-by: Bjorn Helgaas --- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c index b7c3a5ea1fca..232f9254c11a 100644 --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -120,6 +120,7 @@ int pci_claim_resource(struct pci_dev *dev, int resource) if (!root) { dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible bridge window\n", resource, res); + res->flags |= IORESOURCE_UNSET; return -EINVAL; } @@ -127,6 +128,7 @@ int pci_claim_resource(struct pci_dev *dev, int resource) if (conflict) { dev_info(&dev->dev, "can't claim BAR %d %pR: address conflict with %s %pR\n", resource, res, conflict->name, conflict); + res->flags |= IORESOURCE_UNSET; return -EBUSY; }