From patchwork Mon Dec 6 22:27:23 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 12659919 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 16609C41535 for ; Mon, 6 Dec 2021 22:28:03 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.239879.415840 (Exim 4.92) (envelope-from ) id 1muMSG-0001WW-Vv; Mon, 06 Dec 2021 22:27:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 239879.415840; Mon, 06 Dec 2021 22:27:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1muMSG-0001WP-Sw; Mon, 06 Dec 2021 22:27:28 +0000 Received: by outflank-mailman (input) for mailman id 239879; Mon, 06 Dec 2021 22:27:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1muMSF-0001Vt-FB for xen-devel@lists.xenproject.org; Mon, 06 Dec 2021 22:27:27 +0000 Received: from galois.linutronix.de (galois.linutronix.de [2a0a:51c0:0:12e:550::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id afc47430-56e3-11ec-a5e1-b9374ead2679; Mon, 06 Dec 2021 23:27:26 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: afc47430-56e3-11ec-a5e1-b9374ead2679 Message-ID: <20211206210147.872865823@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1638829644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TvVbtaLszVomfbTSaDkZ3Si83Q0PTUXmzyd/sxp3aOQ=; b=2PszHZiuiUTEj+gbLOwH5J07JyOXMbPmbCF5/f0ECB+TDx6fg7HRqd/7nSafRiLEh/tB2J I89obIOz4EfihV8wPu6DVbEqAjw/vu0lG3MVaBJQOCX84dIVCgJcpP/4YaTYj0DWyUOU+p QY7yu7nySNOGDJllJoRD8mO5pRKX6dZ+TpEE7VtehF+zj9YNKxWJrbFRJPs4IpnpV7iPLb eXidnoRUF/iI20Q4u50DI+RHcaKyBY/xpS4sXM1RqwV+zb/rkRAS11jus+lRlFQbQ+/IC4 zfPKJkcA3/LscOUNOfG7uESwv6dj4mHkFlfcsQphYvz9RbwoDVZGHnz96iSF7w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1638829644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TvVbtaLszVomfbTSaDkZ3Si83Q0PTUXmzyd/sxp3aOQ=; b=dTYY6yq8X+q85zEA0MFqc5lmEol5cxwjMuFVu15JeS/3f+qTFpB+7//Ug3/O6D2uzzNFJo H/Ml5sGXok1eYqCQ== From: Thomas Gleixner To: LKML Cc: Bjorn Helgaas , Marc Zygnier , Alex Williamson , Kevin Tian , Jason Gunthorpe , Megha Dey , Ashok Raj , linux-pci@vger.kernel.org, Cedric Le Goater , Michael Ellerman , Paul Mackerras , Benjamin Herrenschmidt , linuxppc-dev@lists.ozlabs.org, Juergen Gross , Thomas Bogendoerfer , linux-mips@vger.kernel.org, Kalle Valo , Greg Kroah-Hartman , sparclinux@vger.kernel.org, x86@kernel.org, xen-devel@lists.xenproject.org, ath11k@lists.infradead.org, Wei Liu , linux-hyperv@vger.kernel.org, Christian Borntraeger , Heiko Carstens Subject: [patch V2 00/23] genirq/msi, PCI/MSI: Spring cleaning - Part 1 MIME-Version: 1.0 Date: Mon, 6 Dec 2021 23:27:23 +0100 (CET) The [PCI] MSI code has gained quite some warts over time. A recent discussion unearthed a shortcoming: the lack of support for expanding PCI/MSI-X vectors after initialization of MSI-X. PCI/MSI-X has no requirement to setup all vectors when MSI-X is enabled in the device. The non-used vectors have just to be masked in the vector table. For PCI/MSI this is not possible because the number of vectors cannot be changed after initialization. The PCI/MSI code, but also the core MSI irq domain code are built around the assumption that all required vectors are installed at initialization time and freed when the device is shut down by the driver. Supporting dynamic expansion at least for MSI-X is important for VFIO so that the host side interrupts for passthrough devices can be installed on demand. This is the first part of a large (total 101 patches) series which refactors the [PCI]MSI infrastructure to make runtime expansion of MSI-X vectors possible. The last part (10 patches) provide this functionality. The first part is mostly a cleanup which consolidates code, moves the PCI MSI code into a separate directory and splits it up into several parts. No functional change intended except for patch 2/N which changes the behaviour of pci_get_vector()/affinity() to get rid of the assumption that the provided index is the "index" into the descriptor list instead of using it as the actual MSI[X] index as seen by the hardware. This would break users of sparse allocated MSI-X entries, but non of them use these functions. This series is based on 5.16-rc2 and also available via git: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v2-part-1 For the curious who can't wait for the next part to arrive the full series is available via: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v2-part-3 V1 of this series can be found here: https://lore.kernel.org/r/20211126222700.862407977@linutronix.de Changes versus V1: - Add missing includes and use correct variable name in legacy code - Cedric - Moved the MSI lock from struct device to struct pci_dev - New patch This is really PCI/MSI specific and there is no point to have it in every struct device. Neither does it make sense to hide it in msi_device_data as the V1 series part 2 did. - Picked up Reviewed/Tested/Acked-by tags as appropriate Thanks, tglx --- arch/powerpc/platforms/4xx/msi.c | 281 ------------ b/Documentation/driver-api/pci/pci.rst | 2 b/arch/mips/pci/msi-octeon.c | 32 - b/arch/powerpc/platforms/4xx/Makefile | 1 b/arch/powerpc/platforms/cell/axon_msi.c | 2 b/arch/powerpc/platforms/powernv/pci-ioda.c | 4 b/arch/powerpc/platforms/pseries/msi.c | 6 b/arch/powerpc/sysdev/Kconfig | 6 b/arch/s390/pci/pci_irq.c | 4 b/arch/sparc/kernel/pci_msi.c | 4 b/arch/x86/hyperv/irqdomain.c | 55 -- b/arch/x86/include/asm/x86_init.h | 6 b/arch/x86/include/asm/xen/hypervisor.h | 8 b/arch/x86/kernel/apic/msi.c | 8 b/arch/x86/kernel/x86_init.c | 12 b/arch/x86/pci/xen.c | 19 b/drivers/base/core.c | 1 b/drivers/irqchip/irq-gic-v2m.c | 1 b/drivers/irqchip/irq-gic-v3-its-pci-msi.c | 1 b/drivers/irqchip/irq-gic-v3-mbi.c | 1 b/drivers/net/wireless/ath/ath11k/pci.c | 2 b/drivers/pci/Makefile | 3 b/drivers/pci/msi/Makefile | 7 b/drivers/pci/msi/irqdomain.c | 267 +++++++++++ b/drivers/pci/msi/legacy.c | 79 +++ b/drivers/pci/msi/msi.c | 647 ++++------------------------ b/drivers/pci/msi/msi.h | 39 + b/drivers/pci/msi/pcidev_msi.c | 43 + b/drivers/pci/pci-sysfs.c | 7 b/drivers/pci/probe.c | 4 b/drivers/pci/xen-pcifront.c | 2 b/include/linux/device.h | 2 b/include/linux/msi.h | 136 ++--- b/include/linux/pci.h | 2 b/kernel/irq/msi.c | 41 + 35 files changed, 702 insertions(+), 1033 deletions(-)