Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Farhan Ali" <alifm@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
	linux-s390@vger.kernel.org, linux-pci@vger.kernel.org,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>
Subject: Re: [PATCH v22 4/4] PCI/MSI: Enable memory decoding before restoring MSI-X messages
Date: Mon, 20 Jul 2026 19:51:25 +0000	[thread overview]
Message-ID: <20260720195126.0CA111F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720192505.2957-5-alifm@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing flush of posted MMIO writes to MSI-X vector control before disabling memory decoding.
--

--- Patch [4]: [PATCH v22 4/4] PCI/MSI: Enable memory decoding before restoring MSI-X messages ---
commit 42ede3312753d558e00e2b7331687e3440f9c013
Author: Farhan Ali <alifm@linux.ibm.com>

PCI/MSI: Enable memory decoding before restoring MSI-X messages

This commit temporarily enables the memory decoding bit in the PCI command
register while restoring MSI-X state, as the device's saved state may not
have it enabled. It restores the original command register state after
the MSI-X table updates are complete.

> diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c
> index 209373c92e9e1..79c7e84d314b7 100644
> --- a/drivers/pci/msi/msi.c
> +++ b/drivers/pci/msi/msi.c

[ ... ]

> @@ -889,6 +898,7 @@ void __pci_restore_msix_state(struct pci_dev *dev)
>  			pci_msix_write_vector_ctrl(entry, entry->pci.msix_ctrl);
>  		}
>  	}
>  
> +	pci_write_config_word(dev, PCI_COMMAND, cmd);

[Severity: High]
Could this cause a regression where the configuration write arrives before
the posted memory writes to the MSI-X table have completed?

During __pci_restore_msix_state(), the loop updates the MSI-X table using
pci_msix_write_vector_ctrl(), which issues posted memory writes.

Because PCIe ordering rules allow configuration writes to pass posted memory
writes, this configuration write might arrive at the endpoint first.

If the restored cmd value disables memory decoding, the earlier posted
memory writes might be dropped as unsupported requests by the endpoint. This
could leave MSI-X interrupts broken after resume, and might trigger advanced
error reporting faults.

Does the MSI-X table need a read flush before the command register is
restored?

>  	pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720192505.2957-1-alifm@linux.ibm.com?part=4

      reply	other threads:[~2026-07-20 19:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 19:25 [PATCH v22 0/4] [PCI] Error recovery for vfio-pci devices on s390x Farhan Ali
2026-07-20 19:25 ` [PATCH v22 1/4] PCI: Allow per function PCI slots to fix slot reset on s390 Farhan Ali
2026-07-20 19:39   ` sashiko-bot
2026-07-20 19:25 ` [PATCH v22 2/4] PCI: Avoid saving config space state if inaccessible Farhan Ali
2026-07-20 19:42   ` sashiko-bot
2026-07-20 19:25 ` [PATCH v22 3/4] PCI: Fail FLR when config space is inaccessible Farhan Ali
2026-07-20 19:38   ` sashiko-bot
2026-07-20 19:25 ` [PATCH v22 4/4] PCI/MSI: Enable memory decoding before restoring MSI-X messages Farhan Ali
2026-07-20 19:51   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260720195126.0CA111F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=alifm@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox