From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754938AbdGCSLs (ORCPT ); Mon, 3 Jul 2017 14:11:48 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:54806 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752370AbdGCSLq (ORCPT ); Mon, 3 Jul 2017 14:11:46 -0400 Date: Mon, 3 Jul 2017 19:11:28 +0100 From: Russell King - ARM Linux To: Bjorn Helgaas Cc: Marc Gonzalez , Mark Rutland , Mason , Marc Zyngier , linux-pci , Thibaud Cornic , Ard Biesheuvel , LKML , Greg Kroah-Hartman , Thomas Gleixner , Linux ARM Subject: Re: [PATCH v9 2/3] PCI: Add tango PCIe host bridge support Message-ID: <20170703181128.GD4902@n2100.armlinux.org.uk> References: <987fac41-80dc-f1d0-ec0b-91ae57b91bfd@sigmadesigns.com> <20170702231811.GJ18324@bhelgaas-glaptop.roam.corp.google.com> <79382219-c730-da78-3e5f-5abf3173d7ac@sigmadesigns.com> <20170703134031.GG13824@bhelgaas-glaptop.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170703134031.GG13824@bhelgaas-glaptop.roam.corp.google.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 03, 2017 at 08:40:31AM -0500, Bjorn Helgaas wrote: > The problem is serializing vs. memory accesses, since they don't use > any wrappers. However, they are ioremapped(), so it's at least > conceivable that another solution would be to use VM to trap those > accesses. I'm not a VM person, so I don't know whether that's > feasible in Linux. Bjorn, You're forgetting that MMIO (iow, memory returned by ioremap()) must be accessed through the appropriate accessors, and must not be directly dereferenced in C. (We do have buggy drivers that do that but they are buggy, and in many cases are getting attention to fix that.) However, adding a spinlock into them is really not nice, because it adds extra overhead that's only necessary for rare cases like Sigma Designs - especially when you consider that these accessors are used for all MMIO accesses, not just PCI. It would effectively mean that we end up serialising all MMIO accesses throughout the kernel when Sigma Designs SoCs are enabled, destroying some of the SMP benefit. I don't think we can sanely use the MMU to trap those accesses either, that would mean sending IPIs to tell other CPUs to do something, and waiting for them to respond - which can deadlock if we're already in an IRQ-protected region (iirc, config accesses are made with IRQs off.) I don't think there's an easy solution to this problem - and I'm not sure that stop_machine() can be made to work in this path (which needs a process context). I have a suspicion that the Sigma Designs PCI implementation is just soo insane that it's never going to work reliably in a multi-SoC kernel without introducing severe performance issues for everyone else. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.