From patchwork Wed Jul 21 19:11:27 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 1508390 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=pEtE4n9a; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=vcfPvsdU; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4GVQbq263Yz9sWw for ; Thu, 22 Jul 2021 05:28:23 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240140AbhGUSro (ORCPT ); Wed, 21 Jul 2021 14:47:44 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:48968 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232052AbhGUSro (ORCPT ); Wed, 21 Jul 2021 14:47:44 -0400 Message-Id: <20210721192650.106154171@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1626895699; 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: references:references; bh=OrDJU+xft+e5MU/yz4DSTjhy6EYE85pzXmPlv5dSTyM=; b=pEtE4n9a+U9pdcmzFrnqriRsVoeLABV/5mE9m1mj9qgaRvtV8x+UV1m/e/2ujmqUQuN2gG pLW/96aL2/XHMTNB5j+W7tMkRf3QCr6u0WXmd/hwVdI52LyG0ovT4HNcCwAtQ1NZ+fVPoW 1j4OqVhVTXz0vRazP+gY11TbJO/AkH48Nf5BNSoMXW7y7g6EuwtjzuukvvzUhYgbRHf1/0 6ah45BoEH2E18P6j+UmrqKs/vo9xulLWee+aUe5KEFOJbe3fv0lU8W83znOCdqmDEpHt05 2Hjne6ETdj6z7WQ/OF3oO0WOcuDpSBZR3lbNOoZwKWNkruxzIWTRi0NLOlv5kw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1626895699; 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: references:references; bh=OrDJU+xft+e5MU/yz4DSTjhy6EYE85pzXmPlv5dSTyM=; b=vcfPvsdU7UXpTnUyVOh43/yJsMaH4b6FoFNjDn1YBHwJSTaJM1Yi44y+hR042ozTIcpgp1 ezoqCokvU5m9AqAg== Date: Wed, 21 Jul 2021 21:11:27 +0200 From: Thomas Gleixner To: LKML Cc: Alex Williamson , "Raj, Ashok" , "David S. Miller" , Bjorn Helgaas , linux-pci@vger.kernel.org, Kevin Tian , Marc Zyngier , Ingo Molnar , x86@kernel.org Subject: [patch 1/8] PCI/MSI: Enable and mask MSIX early References: <20210721191126.274946280@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org The ordering of MSI-X enable in hardware is disfunctional: 1) MSI-X is disabled in the control register 2) Various setup functions 3) pci_msi_setup_msi_irqs() is invoked which ends up accessing the MSI-X table entries 4) MSI-X is enabled and masked in the control register with the comment that enabling is required for some hardware to access the MSI-X table #4 obviously contradicts #3. The history of this is an issue with the NIU hardware. When #4 was introduced the table access actually happened in msix_program_entries() which was invoked after enabling and masking MSI-X. This was changed in commit d71d6432e105 ("PCI/MSI: Kill redundant call of irq_set_msi_desc() for MSI-X interrupts") which removed the table write from msix_program_entries(). Interestingly enough nobody noticed and either NIU still works or it did not get any testing with a kernel 3.19 or later. Nevertheless this is inconsistent and there is no reason why MSI-X can't be enabled and masked in the control register early on, i.e. move #4 above to #1. This preserves the NIU workaround and has no side effects on other hardware. Fixes: d71d6432e105 ("PCI/MSI: Kill redundant call of irq_set_msi_desc() for MSI-X interrupts") Signed-off-by: Thomas Gleixner Cc: David S. Miller Cc: Bjorn Helgaas Cc: linux-pci@vger.kernel.org Reviewed-by: Ashok Raj --- drivers/pci/msi.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -772,18 +772,25 @@ static int msix_capability_init(struct p u16 control; void __iomem *base; - /* Ensure MSI-X is disabled while it is set up */ - pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0); + /* + * Some devices require MSI-X to be enabled before the MSI-X + * registers can be accessed. Mask all the vectors to prevent + * interrupts coming in before they're fully set up. + */ + pci_msix_clear_and_set_ctrl(dev, 0, PCI_MSIX_FLAGS_MASKALL | + PCI_MSIX_FLAGS_ENABLE); pci_read_config_word(dev, dev->msix_cap + PCI_MSIX_FLAGS, &control); /* Request & Map MSI-X table region */ base = msix_map_region(dev, msix_table_size(control)); - if (!base) - return -ENOMEM; + if (!base) { + ret = -ENOMEM; + goto out_disable; + } ret = msix_setup_entries(dev, base, entries, nvec, affd); if (ret) - return ret; + goto out_disable; ret = pci_msi_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX); if (ret) @@ -794,14 +801,6 @@ static int msix_capability_init(struct p if (ret) goto out_free; - /* - * Some devices require MSI-X to be enabled before we can touch the - * MSI-X registers. We need to mask all the vectors to prevent - * interrupts coming in before they're fully set up. - */ - pci_msix_clear_and_set_ctrl(dev, 0, - PCI_MSIX_FLAGS_MASKALL | PCI_MSIX_FLAGS_ENABLE); - msix_program_entries(dev, entries); ret = populate_msi_sysfs(dev); @@ -836,6 +835,9 @@ static int msix_capability_init(struct p out_free: free_msi_irqs(dev); +out_disable: + pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0); + return ret; } From patchwork Wed Jul 21 19:11:28 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 1508391 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=HZHcDVLp; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=ao/br370; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4GVQbq6Wvsz9sW5 for ; Thu, 22 Jul 2021 05:28:23 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240167AbhGUSrp (ORCPT ); Wed, 21 Jul 2021 14:47:45 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:48984 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240157AbhGUSrp (ORCPT ); Wed, 21 Jul 2021 14:47:45 -0400 Message-Id: <20210721192650.268814107@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1626895700; 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: references:references; bh=IZTd+XpoWYmhr0WH7I9so3BgwJiydYTy0Kw6dYqrbAw=; b=HZHcDVLp7V5NBpY63+8Dp2jJiSsG8UGbza6WnApcev5BkbrgJM2wwhffvBseMA0zRMyZOW m/Cs/XPK99CKjWBJe7vMg3mUygerqVDSxJpHk9u1hFUmRetll0fesPDk1lIcnXqUXQByu0 xH39XewcCC1u7p8+SX8F7Av1UJbeCVMaAt0vJYzL5DcZqrVRJTHo3gLOFDCREH7nICTtlq FRhHwIbe6T7sCkzczTSVo235+NeBD9s2Vl7oiI44gteEZ0ip9npngKcznPMNA1eFJqQQyz NELgdsC4zHnds6me8UiQQbpJN9gjFSg40/+Ijvm1pzl129S74l4UJS3L4fwtlw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1626895700; 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: references:references; bh=IZTd+XpoWYmhr0WH7I9so3BgwJiydYTy0Kw6dYqrbAw=; b=ao/br370RWx5Uo3O3m9u3vvJUwYghNoEuGR1dAbe5NzLk78cWTMOjVVfPHDGLoksSTQwi8 5hwZZwDjKTuFGNBQ== Date: Wed, 21 Jul 2021 21:11:28 +0200 From: Thomas Gleixner To: LKML Cc: Alex Williamson , "Raj, Ashok" , Bjorn Helgaas , linux-pci@vger.kernel.org, "David S. Miller" , Kevin Tian , Marc Zyngier , Ingo Molnar , x86@kernel.org Subject: [patch 2/8] PCI/MSI: Mask all unused MSI-X entries References: <20210721191126.274946280@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org When MSI-X is enabled the ordering of calls is: msix_map_region(); msix_setup_entries(); pci_msi_setup_msi_irqs(); msix_program_entries(); This has a few interesting issues: 1) msix_setup_entries() allocates the msi descriptors and initializes them except for the msi_desc:masked member which is left zero initialized. 2) pci_msi_setup_msi_irqs() allocates the interrupt descriptors and sets up the MSI interrupts which ends up in pci_write_msi_msg() unless the interrupt chip provides it's own irq_write_msi_msg() function. 3) msix_program_entries() does not do what the name suggests. It solely updates the entries array (if not NULL) and initializes the masked member for each msi descriptor by reading the hardware state and then masks the entry. Obviously this has some issues: 1) The uninitialized masked member of msi_desc prevents the enforcement of masking the entry in pci_write_msi_msg() depending on the cached masked bit. Aside of that half initialized data is a NONO in general 2) msix_program_entries() only ensures that the actually allocated entries are masked. This is wrong as experimentation with crash testing and crash kernel kexec has shown. This limited testing unearthed that when the production kernel had more entries in use and unmasked when it crashed and the crash kernel allocated a smaller amount of entries, then a full scan of all entries found unmasked entries which were in use in the production kernel. This is obviously a device or emulation issue as the device reset should mask all MSI-X table entries, but obviously that's just part of the paper specification. Cure this by: 1) Masking all table entries in hardware 2) Initializing msi_desc::masked in msix_setup_entries() 3) Removing the mask dance in msix_program_entries() 4) Renaming msix_program_entries() to msix_update_entries() to reflect the purpose of that function. As the masking of unused entries has never been done the Fixes tag refers to a commit in: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Fixes: f036d4ea5fa7 ("[PATCH] ia32 Message Signalled Interrupt support") Signed-off-by: Thomas Gleixner Cc: Bjorn Helgaas Cc: linux-pci@vger.kernel.org Reviewed-by: Marc Zyngier --- drivers/pci/msi.c | 45 +++++++++++++++++++++++++++------------------ 1 file changed, 27 insertions(+), 18 deletions(-) --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -691,6 +691,7 @@ static int msix_setup_entries(struct pci { struct irq_affinity_desc *curmsk, *masks = NULL; struct msi_desc *entry; + void __iomem *addr; int ret, i; int vec_count = pci_msix_vec_count(dev); @@ -711,6 +712,7 @@ static int msix_setup_entries(struct pci entry->msi_attrib.is_msix = 1; entry->msi_attrib.is_64 = 1; + if (entries) entry->msi_attrib.entry_nr = entries[i].entry; else @@ -722,6 +724,10 @@ static int msix_setup_entries(struct pci entry->msi_attrib.default_irq = dev->irq; entry->mask_base = base; + addr = pci_msix_desc_addr(entry); + if (addr) + entry->masked = readl(addr + PCI_MSIX_ENTRY_VECTOR_CTRL); + list_add_tail(&entry->list, dev_to_msi_list(&dev->dev)); if (masks) curmsk++; @@ -732,26 +738,25 @@ static int msix_setup_entries(struct pci return ret; } -static void msix_program_entries(struct pci_dev *dev, - struct msix_entry *entries) +static void msix_update_entries(struct pci_dev *dev, struct msix_entry *entries) { struct msi_desc *entry; - int i = 0; - void __iomem *desc_addr; for_each_pci_msi_entry(entry, dev) { - if (entries) - entries[i++].vector = entry->irq; + if (entries) { + entries->vector = entry->irq; + entries++; + } + } +} - desc_addr = pci_msix_desc_addr(entry); - if (desc_addr) - entry->masked = readl(desc_addr + - PCI_MSIX_ENTRY_VECTOR_CTRL); - else - entry->masked = 0; +static void msix_mask_all(void __iomem *base, int tsize) +{ + u32 ctrl = PCI_MSIX_ENTRY_CTRL_MASKBIT; + int i; - msix_mask_irq(entry, 1); - } + for (i = 0; i < tsize; i++, base += PCI_MSIX_ENTRY_SIZE) + writel(ctrl, base + PCI_MSIX_ENTRY_VECTOR_CTRL); } /** @@ -768,9 +773,9 @@ static void msix_program_entries(struct static int msix_capability_init(struct pci_dev *dev, struct msix_entry *entries, int nvec, struct irq_affinity *affd) { - int ret; - u16 control; void __iomem *base; + int ret, tsize; + u16 control; /* * Some devices require MSI-X to be enabled before the MSI-X @@ -782,12 +787,16 @@ static int msix_capability_init(struct p pci_read_config_word(dev, dev->msix_cap + PCI_MSIX_FLAGS, &control); /* Request & Map MSI-X table region */ - base = msix_map_region(dev, msix_table_size(control)); + tsize = msix_table_size(control); + base = msix_map_region(dev, tsize); if (!base) { ret = -ENOMEM; goto out_disable; } + /* Ensure that all table entries are masked. */ + msix_mask_all(base, tsize); + ret = msix_setup_entries(dev, base, entries, nvec, affd); if (ret) goto out_disable; @@ -801,7 +810,7 @@ static int msix_capability_init(struct p if (ret) goto out_free; - msix_program_entries(dev, entries); + msix_update_entries(dev, entries); ret = populate_msi_sysfs(dev); if (ret) From patchwork Wed Jul 21 19:11:29 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 1508392 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=ij+tOA1+; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=8asa2EOR; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4GVQbr6HYPz9sX3 for ; Thu, 22 Jul 2021 05:28:24 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240205AbhGUSrr (ORCPT ); Wed, 21 Jul 2021 14:47:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240182AbhGUSrq (ORCPT ); Wed, 21 Jul 2021 14:47:46 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D825FC061575; Wed, 21 Jul 2021 12:28:22 -0700 (PDT) Message-Id: <20210721192650.408910288@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1626895701; 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: references:references; bh=KWtC2UPjPY3Lp8DJcp7b3mXMDtwP0YVFUEtqHXYFvGM=; b=ij+tOA1+22K/HklGs9TlrUVUZV7/dMj5ggQdcdg4/57Joy0kopGpeFPXbAnmFRxrgbjXjy gBtiVkrAcNtp9USFAuKm2Vp5Qf6fK/qjK6DftI2L3SfNlP9V9z6A0npWUrV28lAWcZpTLF Vjz5WNoSi8hZ9m7yRF9+IYP7Ei+w2f8nGPAb6IWIqLBwM2Mxg30OSC0EEZF0W0qH4GycTv iQsHx4Bl7h5549h4be8xIWzLq4Vzg6Z+8CzKwPf+iUtItG9IBq382EYnfNzoWloMN5yHYs mD4nJDXUewubAc463bk0IUhUuGCFEHpqr5VqQCjcBePNkymgS1LMG4epcOskMQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1626895701; 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: references:references; bh=KWtC2UPjPY3Lp8DJcp7b3mXMDtwP0YVFUEtqHXYFvGM=; b=8asa2EORheXG28I5hV5q2mJLgfLpZhlup17vHg1Xv3nEz8yqaK8FPoYNetz2p2jHfMyXdh GhiEdrx0B3LPWYCw== Date: Wed, 21 Jul 2021 21:11:29 +0200 From: Thomas Gleixner To: LKML Cc: Alex Williamson , "Raj, Ashok" , Kevin Tian , Bjorn Helgaas , linux-pci@vger.kernel.org, "David S. Miller" , Marc Zyngier , Ingo Molnar , x86@kernel.org Subject: [patch 3/8] PCI/MSI: Enforce that MSI-X table entry is masked for update References: <20210721191126.274946280@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org The specification states: For MSI-X, a function is permitted to cache Address and Data values from unmasked MSI-X Table entries. However, anytime software unmasks a currently masked MSI-X Table entry either by clearing its Mask bit or by clearing the Function Mask bit, the function must update any Address or Data values that it cached from that entry. If software changes the Address or Data value of an entry while the entry is unmasked, the result is undefined. The Linux kernel's MSI-X support never enforced that the entry is masked before the entry is modified hence the Fixes tag refers to a commit in: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Enforce the entry to be masked across the update. There is no point in enforcing this to be handled at all possible call sites as this is just pointless code duplication and the common update function is the obvious place to enforce this. Reported-by: Kevin Tian Fixes: f036d4ea5fa7 ("[PATCH] ia32 Message Signalled Interrupt support") Signed-off-by: Thomas Gleixner Cc: Bjorn Helgaas Cc: linux-pci@vger.kernel.org --- drivers/pci/msi.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -289,13 +289,28 @@ void __pci_write_msi_msg(struct msi_desc /* Don't touch the hardware now */ } else if (entry->msi_attrib.is_msix) { void __iomem *base = pci_msix_desc_addr(entry); + bool unmasked = !(entry->masked & PCI_MSIX_ENTRY_CTRL_MASKBIT); if (!base) goto skip; + /* + * The specification mandates that the entry is masked + * when the message is modified: + * + * "If software changes the Address or Data value of an + * entry while the entry is unmasked, the result is + * undefined." + */ + if (unmasked) + __pci_msix_desc_mask_irq(entry, PCI_MSIX_ENTRY_CTRL_MASKBIT); + writel(msg->address_lo, base + PCI_MSIX_ENTRY_LOWER_ADDR); writel(msg->address_hi, base + PCI_MSIX_ENTRY_UPPER_ADDR); writel(msg->data, base + PCI_MSIX_ENTRY_DATA); + + if (unmasked) + __pci_msix_desc_mask_irq(entry, 0); } else { int pos = dev->msi_cap; u16 msgctl; From patchwork Wed Jul 21 19:11:30 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 1508393 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=Muw92HYd; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=doh6xw3u; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4GVQbt3nTjz9sX5 for ; Thu, 22 Jul 2021 05:28:26 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240200AbhGUSrr (ORCPT ); Wed, 21 Jul 2021 14:47:47 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:48984 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240190AbhGUSrr (ORCPT ); Wed, 21 Jul 2021 14:47:47 -0400 Message-Id: <20210721192650.499597025@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1626895702; 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: references:references; bh=LF8YFdjdkW8dMUJ0dZ2Yk1aIs4MGBPEdVHXD+nWbtGI=; b=Muw92HYdHxVzCu7S9yYuM7zdRsR61lahosE1mZU8/UdW0GoBq7cEPXabH21mcefL1Rra7d qkPqtI3Ja/IiZXLeANBFANYAy1Ov0nSpxNnVp41NgNz60TqTTJV1rTDGWDjyChWRPLy+vv JTUwpCZE7jy6LwnR9woDXjiqYDAqztF7xgnkL6QUulUAV5+xXT5oJnM4WXYhlOcesgQfMm SlE11ULByHEgQqaMnoQeP/z2gqdSFsp2at3a/M/KbA3mLHvCLJSAOtwyyCbcDyFqujTZ4w 2Rp79ogDyqAghbOdAAkY/RDVugkd4DvYrew0Ori7ZKseim/40LgwcXMNfQjG4A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1626895702; 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: references:references; bh=LF8YFdjdkW8dMUJ0dZ2Yk1aIs4MGBPEdVHXD+nWbtGI=; b=doh6xw3uj3DCH7etF0JQBaE6sQaBR/6H+8CttmJ7/NaLMjoz/lAQqw8MKuTBzXfaQaTCWg g4r29pYjBHmDwHAQ== Date: Wed, 21 Jul 2021 21:11:30 +0200 From: Thomas Gleixner To: LKML Cc: Alex Williamson , "Raj, Ashok" , Bjorn Helgaas , linux-pci@vger.kernel.org, "David S. Miller" , Kevin Tian , Marc Zyngier , Ingo Molnar , x86@kernel.org Subject: [patch 4/8] PCI/MSI: Enforce MSI[X] entry updates to be visible References: <20210721191126.274946280@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Nothing enforces the posted writes to be visible when the function returns. Flush them even if the flush might be redundant when the entry is masked already as the unmask will flush as well. This is either setup or a rare affinity change event so the extra flush is not the end of the world. While this is more a theoretical issue especially the X86 MSI affinity stter mechanism relies on the assumption that the update has reached the hardware when the function returns. Again, as this never has been enfocred the Fixes tag refers to a commit in: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Fixes: f036d4ea5fa7 ("[PATCH] ia32 Message Signalled Interrupt support") Signed-off-by: Thomas Gleixner Cc: Bjorn Helgaas Cc: linux-pci@vger.kernel.org --- drivers/pci/msi.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -311,6 +311,9 @@ void __pci_write_msi_msg(struct msi_desc if (unmasked) __pci_msix_desc_mask_irq(entry, 0); + + /* Ensure that the writes are visible in the device */ + readl(base + PCI_MSIX_ENTRY_DATA); } else { int pos = dev->msi_cap; u16 msgctl; @@ -331,6 +334,8 @@ void __pci_write_msi_msg(struct msi_desc pci_write_config_word(dev, pos + PCI_MSI_DATA_32, msg->data); } + /* Ensure that the writes are visible in the device */ + pci_read_config_word(dev, pos + PCI_MSI_FLAGS, &msgctl); } skip: From patchwork Wed Jul 21 19:11:31 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 1508394 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=1uOZ/4pk; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=ojhhhtU+; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4GVQbw2QyZz9sX3 for ; Thu, 22 Jul 2021 05:28:28 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240236AbhGUSrt (ORCPT ); Wed, 21 Jul 2021 14:47:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240231AbhGUSrt (ORCPT ); Wed, 21 Jul 2021 14:47:49 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E21CC061575; Wed, 21 Jul 2021 12:28:25 -0700 (PDT) Message-Id: <20210721192650.594990678@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1626895704; 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: references:references; bh=4sVdT7vB64GCrxlmQGZUm2NVgD4dstdg4hyqLY16mPw=; b=1uOZ/4pkUaSan/C1chFJ8DpZJmafXWFLNUDDLVblCwP27CBGd7Zj4qRgP/lr0nf+lOx4Ni yOdqGtk0GSMjgSPTT6u0jpiyYU8HZbpkMiXl3R5leUADiqIL69JwLUDbGA5z27cGYxxJwU BwjBcS1CcmfvrQ8pGvxQfhs04DdWLzmBlxgZVKZJq2cBDEy6rZ4CBysglzUuw2Py73+A5I na4h5Nb/RpSBiPc7puKkdiHWvyrBAbT69L5jenZSbQRV11WmG/3Xnrt06Mru2+YaUSVY0+ cauXy893Pf+IX57kc6ZU6YhEo9V+TJoPcb3vhKlC2W/44I78oPTyIcX6XfeC6g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1626895704; 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: references:references; bh=4sVdT7vB64GCrxlmQGZUm2NVgD4dstdg4hyqLY16mPw=; b=ojhhhtU+zeNQkHNiFTc/chpXxVp5wXTrdMabsOsGyFz93nuaKAq/Cre6kxx/Q65MwsMHoe FbC3VVgBUy5A0lCg== Date: Wed, 21 Jul 2021 21:11:31 +0200 From: Thomas Gleixner To: LKML Cc: Alex Williamson , "Raj, Ashok" , Bjorn Helgaas , linux-pci@vger.kernel.org, "David S. Miller" , Kevin Tian , Marc Zyngier , Ingo Molnar , x86@kernel.org Subject: [patch 5/8] PCI/MSI: Simplify msi_verify_entries() References: <20210721191126.274946280@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org No point in looping over all entries when 64bit addressing mode is enabled for nothing. Signed-off-by: Thomas Gleixner Cc: Bjorn Helgaas Cc: linux-pci@vger.kernel.org --- drivers/pci/msi.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -612,8 +612,11 @@ static int msi_verify_entries(struct pci { struct msi_desc *entry; + if (!dev->no_64bit_msi) + return 0; + for_each_pci_msi_entry(entry, dev) { - if (entry->msg.address_hi && dev->no_64bit_msi) { + if (entry->msg.address_hi) { pci_err(dev, "arch assigned 64-bit MSI address %#x%08x but device only supports 32 bits\n", entry->msg.address_hi, entry->msg.address_lo); return -EIO; From patchwork Wed Jul 21 19:11:32 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 1508395 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=cKRWLDWn; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=CF8mopfF; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4GVQby5c2Lz9sX3 for ; Thu, 22 Jul 2021 05:28:30 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240182AbhGUSrw (ORCPT ); Wed, 21 Jul 2021 14:47:52 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:49030 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240226AbhGUSru (ORCPT ); Wed, 21 Jul 2021 14:47:50 -0400 Message-Id: <20210721192650.687529735@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1626895705; 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: references:references; bh=pwHEEYmLAbUc4i2qr603Zxpv2QyDkJm208V/NepdGao=; b=cKRWLDWnCs2i9P0yqRlfEEvw16yy1QhLzO0mKEkVltKeKUKG/i2rIlZspVList17emV6uG xOB4MBzWKeCbAo4DfR2S11GcUK3kM4XieXvYzAuLGlMWzrAwtFPifX+VbgVx445ObhILkY snX0ttokXWqbMZ2w9RP5rutCjsFypMYcWxm0PAAmKhHpsTf2gT2EVuuO1hYSWaQcmPvemm rzw+628qtFFijHyVPn8dFgr13NKHlq49XBlDrWGxstIrAvxT9Ltk2R7Uaw4PU7hxdprWSz 34/BRcIJc4ZSQLc7+mLssYGTkV8PuE3McDX/2/ZUn6FUVJWAO7ZJuWAUWWQbrg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1626895705; 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: references:references; bh=pwHEEYmLAbUc4i2qr603Zxpv2QyDkJm208V/NepdGao=; b=CF8mopfF2J6rXkAA4ZOmfzYvuDdXShQg+P1uoaRCB8D4muX+3bQF7rcUBLZSAhRHllPBhg aDlEPpLnE5MbrhDg== Date: Wed, 21 Jul 2021 21:11:32 +0200 From: Thomas Gleixner To: LKML Cc: Alex Williamson , "Raj, Ashok" , Marc Zyngier , Ingo Molnar , "David S. Miller" , Bjorn Helgaas , linux-pci@vger.kernel.org, Kevin Tian , x86@kernel.org Subject: [patch 6/8] genirq: Provide IRQCHIP_AFFINITY_PRE_STARTUP References: <20210721191126.274946280@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X86 IO/APIC and MSI interrupts (when used without interrupts remapping) require that the affinity setup on startup is done before the interrupt is enabled for the first time as the non-remapped operation mode cannot safely migrate enabled interrupts from arbitrary contexts. Provide a new irq chip flag which allows affected hardware to request this. This has to be opt-in because there have been reports in the past that some interrupt chips cannot handle affinity setting before startup. Fixes: 18404756765c ("genirq: Expose default irq affinity mask (take 3)") Signed-off-by: Thomas Gleixner Cc: Thomas Gleixner Cc: Marc Zyngier Cc: Ingo Molnar --- include/linux/irq.h | 2 ++ kernel/irq/chip.c | 5 ++++- 2 files changed, 6 insertions(+), 1 deletion(-) --- a/include/linux/irq.h +++ b/include/linux/irq.h @@ -569,6 +569,7 @@ struct irq_chip { * IRQCHIP_SUPPORTS_NMI: Chip can deliver NMIs, only for root irqchips * IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND: Invokes __enable_irq()/__disable_irq() for wake irqs * in the suspend path if they are in disabled state + * IRQCHIP_AFFINITY_PRE_STARTUP: Default affinity update before startup */ enum { IRQCHIP_SET_TYPE_MASKED = (1 << 0), @@ -581,6 +582,7 @@ enum { IRQCHIP_SUPPORTS_LEVEL_MSI = (1 << 7), IRQCHIP_SUPPORTS_NMI = (1 << 8), IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND = (1 << 9), + IRQCHIP_AFFINITY_PRE_STARTUP = (1 << 10), }; #include --- a/kernel/irq/chip.c +++ b/kernel/irq/chip.c @@ -265,8 +265,11 @@ int irq_startup(struct irq_desc *desc, b } else { switch (__irq_startup_managed(desc, aff, force)) { case IRQ_STARTUP_NORMAL: + if (d->chip->flags & IRQCHIP_AFFINITY_PRE_STARTUP) + irq_setup_affinity(desc); ret = __irq_startup(desc); - irq_setup_affinity(desc); + if (!(d->chip->flags & IRQCHIP_AFFINITY_PRE_STARTUP)) + irq_setup_affinity(desc); break; case IRQ_STARTUP_MANAGED: irq_do_set_affinity(d, aff, false); From patchwork Wed Jul 21 19:11:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 1508397 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=zT2j3XDP; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=t0pnar27; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4GVQc06Zqnz9sX5 for ; Thu, 22 Jul 2021 05:28:32 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240190AbhGUSry (ORCPT ); Wed, 21 Jul 2021 14:47:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240243AbhGUSrw (ORCPT ); Wed, 21 Jul 2021 14:47:52 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD50AC061575; Wed, 21 Jul 2021 12:28:27 -0700 (PDT) Message-Id: <20210721192650.777524186@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1626895706; 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: references:references; bh=gXoT1JSDwLz5tF/LvOMibPfjcEw9m9vkS4YxgZeoadQ=; b=zT2j3XDPQ7OQ3Ff1b+MxpcdAVEh21bOQzCOKp9f6OCSsIer62PPtI/Y0cXiIOAzDL8CZxn 2KM3IBoJBPRNfPiuWvV1P450sDS77rPyuKMriDqa1mLh/ktIHdMCIlq/qfpwePYWKXtIza PwJ9QHNK3HWYIkBV3VX2/3t6ohMrJUygxlmQhZFcukOZGgxNkQkzaF1pIjRQdTUJxEf8lE 7HX6Slbn4Q5b7YJ0/ueGIPWj0BiUH97Cl/NLFykI9D5xQr5FE5Zxp7DeNzeihtoIGA/vNB z2worL6t50w5Mk0eQVSPHUsMNygvkbBN8kzxtLDrHn+31/aBWxRPbifKBH4ipQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1626895706; 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: references:references; bh=gXoT1JSDwLz5tF/LvOMibPfjcEw9m9vkS4YxgZeoadQ=; b=t0pnar278lCEc4snxylSco8P4VsV1sqDNsa71drDsuc/ejPNItIOQTz39KCFFtpLql5rYu STlgOyH8sOs1IYBQ== Date: Wed, 21 Jul 2021 21:11:33 +0200 From: Thomas Gleixner To: LKML Cc: Alex Williamson , "Raj, Ashok" , x86@kernel.org, "David S. Miller" , Bjorn Helgaas , linux-pci@vger.kernel.org, Kevin Tian , Marc Zyngier , Ingo Molnar Subject: [patch 7/8] x86/ioapic: Force affinity setup before startup References: <20210721191126.274946280@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org The IO/APIC cannot handle interrupt affinity changes safely after startup other than from an interrupt handler. The startup sequence in the generic interrupt code violates that assumption. Mark the irq chip with the new IRQCHIP_AFFINITY_PRE_STARTUP flag so that the default interrupt setting happens before the interrupt is started up for the first time. Fixes: 18404756765c ("genirq: Expose default irq affinity mask (take 3)") Signed-off-by: Thomas Gleixner Cc: x86@kernel.org --- arch/x86/kernel/apic/io_apic.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -1986,7 +1986,8 @@ static struct irq_chip ioapic_chip __rea .irq_set_affinity = ioapic_set_affinity, .irq_retrigger = irq_chip_retrigger_hierarchy, .irq_get_irqchip_state = ioapic_irq_get_chip_state, - .flags = IRQCHIP_SKIP_SET_WAKE, + .flags = IRQCHIP_SKIP_SET_WAKE | + IRQCHIP_AFFINITY_PRE_STARTUP, }; static struct irq_chip ioapic_ir_chip __read_mostly = { @@ -1999,7 +2000,8 @@ static struct irq_chip ioapic_ir_chip __ .irq_set_affinity = ioapic_set_affinity, .irq_retrigger = irq_chip_retrigger_hierarchy, .irq_get_irqchip_state = ioapic_irq_get_chip_state, - .flags = IRQCHIP_SKIP_SET_WAKE, + .flags = IRQCHIP_SKIP_SET_WAKE | + IRQCHIP_AFFINITY_PRE_STARTUP, }; static inline void init_IO_APIC_traps(void) From patchwork Wed Jul 21 19:11:34 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 1508396 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=BkzKRIYs; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=j+Plk8DT; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4GVQbz2lqHz9sX5 for ; Thu, 22 Jul 2021 05:28:31 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240244AbhGUSrx (ORCPT ); Wed, 21 Jul 2021 14:47:53 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:49056 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240246AbhGUSrw (ORCPT ); Wed, 21 Jul 2021 14:47:52 -0400 Message-Id: <20210721192650.867877313@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1626895707; 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: references:references; bh=5qrlEv3rvmev48WbnJCr7JBARBHjEzrTBEeyqZzyuic=; b=BkzKRIYsmCo9nDvtb5bf00bT+AO8kSlr8bXjrysAyaBwRtFcHOYXMe4f+hLHwtwjNkpKSm UIpKxaV6OpbNIbNMZ89PFzXP6/o6nHMsJGQtS/Vq1vsc0uM25GA3j8nmClrjdnpEREjsPW 3tTUtBSv46HCaw0cQMEsvpTNc/e6ld9JG2lcxRtnncqUp8RoykanDI/diO+sNkgGEyxUB4 Dh+YnE7GWQHSDeazJHPfnH9s1zJMMFnT0Qwm/xvXP2ZHUjy64ZMo/PT4xrkRdQgmU0AxWZ rUzw+dBdPh/DzqaL2GkQyWiydf6h3HPNgkCB7o/rmzP4y+J8ASV1j7s1xbaD3g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1626895707; 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: references:references; bh=5qrlEv3rvmev48WbnJCr7JBARBHjEzrTBEeyqZzyuic=; b=j+Plk8DTQ1tF2yqN0XdqRI0R18BoLcNcHr8753Q4wcT2AKGUNOgI8SpzhDqTm86CVjHf5s NXfErO75q0V+ozDg== Date: Wed, 21 Jul 2021 21:11:34 +0200 From: Thomas Gleixner To: LKML Cc: Alex Williamson , "Raj, Ashok" , "David S. Miller" , Bjorn Helgaas , linux-pci@vger.kernel.org, Kevin Tian , Marc Zyngier , Ingo Molnar , x86@kernel.org Subject: [patch 8/8] x86/msi: Force affinity setup before startup References: <20210721191126.274946280@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org The X86 MSI mechanism cannot handle interrupt affinity changes safely after startup other than from an interrupt handler, unless interrupt remapping is enabled. The startup sequence in the generic interrupt code violates that assumption. Mark the irq chips with the new IRQCHIP_AFFINITY_PRE_STARTUP flag so that the default interrupt setting happens before the interrupt is started up for the first time. While the interrupt remapping MSI chip does not require this, there is no point in treating it differently as this might spare an interrupt to a CPU which is not in the default affinity mask. For the non-remapping case go to the direct write path when the interrupt is not yet started similar to the not yet activated case. Fixes: 18404756765c ("genirq: Expose default irq affinity mask (take 3)") Signed-off-by: Thomas Gleixner --- arch/x86/kernel/apic/msi.c | 11 ++++++++--- arch/x86/kernel/hpet.c | 2 +- 2 files changed, 9 insertions(+), 4 deletions(-) --- a/arch/x86/kernel/apic/msi.c +++ b/arch/x86/kernel/apic/msi.c @@ -58,11 +58,13 @@ msi_set_affinity(struct irq_data *irqd, * The quirk bit is not set in this case. * - The new vector is the same as the old vector * - The old vector is MANAGED_IRQ_SHUTDOWN_VECTOR (interrupt starts up) + * - The interrupt is not yet started up * - The new destination CPU is the same as the old destination CPU */ if (!irqd_msi_nomask_quirk(irqd) || cfg->vector == old_cfg.vector || old_cfg.vector == MANAGED_IRQ_SHUTDOWN_VECTOR || + !irqd_is_started(irqd) || cfg->dest_apicid == old_cfg.dest_apicid) { irq_msi_update_msg(irqd, cfg); return ret; @@ -150,7 +152,8 @@ static struct irq_chip pci_msi_controlle .irq_ack = irq_chip_ack_parent, .irq_retrigger = irq_chip_retrigger_hierarchy, .irq_set_affinity = msi_set_affinity, - .flags = IRQCHIP_SKIP_SET_WAKE, + .flags = IRQCHIP_SKIP_SET_WAKE | + IRQCHIP_AFFINITY_PRE_STARTUP, }; int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec, @@ -219,7 +222,8 @@ static struct irq_chip pci_msi_ir_contro .irq_mask = pci_msi_mask_irq, .irq_ack = irq_chip_ack_parent, .irq_retrigger = irq_chip_retrigger_hierarchy, - .flags = IRQCHIP_SKIP_SET_WAKE, + .flags = IRQCHIP_SKIP_SET_WAKE | + IRQCHIP_AFFINITY_PRE_STARTUP, }; static struct msi_domain_info pci_msi_ir_domain_info = { @@ -273,7 +277,8 @@ static struct irq_chip dmar_msi_controll .irq_retrigger = irq_chip_retrigger_hierarchy, .irq_compose_msi_msg = dmar_msi_compose_msg, .irq_write_msi_msg = dmar_msi_write_msg, - .flags = IRQCHIP_SKIP_SET_WAKE, + .flags = IRQCHIP_SKIP_SET_WAKE | + IRQCHIP_AFFINITY_PRE_STARTUP, }; static int dmar_msi_init(struct irq_domain *domain, --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -508,7 +508,7 @@ static struct irq_chip hpet_msi_controll .irq_set_affinity = msi_domain_set_affinity, .irq_retrigger = irq_chip_retrigger_hierarchy, .irq_write_msi_msg = hpet_msi_write_msg, - .flags = IRQCHIP_SKIP_SET_WAKE, + .flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_AFFINITY_PRE_STARTUP, }; static int hpet_msi_init(struct irq_domain *domain,