From: Bjorn Helgaas <helgaas@kernel.org>
To: Vladimir Nedoshivin <gvozd188@mail.ru>
Cc: "Nirmal Patel" <nirmal.patel@linux.intel.com>,
linux-pci@vger.kernel.org,
"Jonathan Derrick" <jonathan.derrick@linux.dev>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Rickey Bartlett" <subtexel@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: vmd: Enable interrupt ordering quirk for Arrow Lake
Date: Thu, 1 Oct 2026 18:07:17 -0500 [thread overview]
Message-ID: <20261001230717.GA2742668@bhelgaas> (raw)
In-Reply-To: <20260910200539.10862-1-gvozd188@mail.ru>
On Fri, Sep 11, 2026 at 12:05:39AM +0400, Vladimir Nedoshivin wrote:
> Intel Arrow Lake VMD device 0xad0b is affected by ARL004. The VMD may
> signal an MSI before preceding posted writes from the child device have
> reached memory, which can cause the demuxed handler to observe stale
> completion data.
>
> The existing VMD_FEAT_INTERRUPT_QUIRK implements Intel's documented
> workaround by issuing a configuration-space read to the MSI initiator
> before dispatching the interrupt.
>
> Enable the existing quirk for 0xad0b as well as 0x7d0b and make the
> comments describe both MTL016 and ARL004.
>
> Tested on an MSI Vector 17 HX AI with Intel VMD 8086:ad0b and an NVMe
> device behind VMD. With the quirk enabled, the NVMe completion stalls
> observed without the workaround are no longer reproduced.
>
> Link: https://bugs.launchpad.net/bugs/2166325
> Signed-off-by: Vladimir Nedoshivin <gvozd188@mail.ru>
Applied on pci/controller/vmd, thanks!
I added the erratum source and text to the commit logs of both the
Meteor Lake quirk and this one:
PCI: vmd: Flush DMA writes before handling MSI on Arrow Lake
Per the Intel Core Ultra Processors (Series 2) Specification Update
(ID 834774 of 9/1/2026), the Arrow Lake VMD device 0xad0b is affected by an
MSI erratum:
ARL004: MSI from VMD-Owned Device May Pass Memory Write
Problem When the storage subsystem is configured to operate in RAID
0 or 1 mode, a Message Signaled Interrupt (MSI) from an
Intel® Volume Management Device (Intel® VMD) owned device
may interrupt a core before a previous write from the device
is completed.
Workaround None identified. The VMD MSI interrupt-handler should
initially perform a dummy register read to the MSI initiator
device prior to any writes to ensure proper PCIe ordering.
...
> ---
> drivers/pci/controller/vmd.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index e45ef8cb16e..9d97a832785 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -94,7 +94,8 @@ enum vmd_features {
> VMD_FEAT_USE_BIOS_INFO = (1 << 6),
>
> /*
> - * Meteor Lake VMD (device ID 0x7d0b) is affected by erratum MTL016:
> + * Some Intel VMD devices are affected by interrupt ordering errata,
> + * including MTL016 (0x7d0b) and ARL004 (0xad0b):
> * the VMD may signal its MSI before the posted writes that carry the
> * child device's DMA data have landed in memory. The demuxed handler
> * then runs against a not-yet-coherent completion queue and misses the
> @@ -131,7 +132,7 @@ static DEFINE_RAW_SPINLOCK(list_lock);
> * @enabled: true if driver enabled IRQ
> * @virq: the virtual IRQ value provided to the requesting driver.
> * @flush_addr: config space address of the initiating device, read before
> - * demuxing to flush its posted writes (MTL016); NULL if the
> + * demuxing to flush its posted writes; NULL if the
> * VMD is not affected.
> *
> * Every MSI/MSI-X IRQ requested for a device in a VMD domain will be mapped to
> @@ -1300,7 +1301,7 @@ static const struct pci_device_id vmd_ids[] = {
> {PCI_VDEVICE(INTEL, 0x7d0b),
> .driver_data = VMD_FEATS_CLIENT | VMD_FEAT_INTERRUPT_QUIRK,},
> {PCI_VDEVICE(INTEL, 0xad0b),
> - .driver_data = VMD_FEATS_CLIENT,},
> + .driver_data = VMD_FEATS_CLIENT | VMD_FEAT_INTERRUPT_QUIRK,},
> {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_VMD_9A0B),
> .driver_data = VMD_FEATS_CLIENT,},
> {PCI_VDEVICE(INTEL, 0xb60b),
>
> base-commit: 95ac22dd4bf13373f90bb6d51bcd1fd1d8f5db54
> --
> 2.53.0
>
prev parent reply other threads:[~2026-10-01 23:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 20:05 Vladimir Nedoshivin
2026-10-01 23:07 ` Bjorn Helgaas [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=20261001230717.GA2742668@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=gvozd188@mail.ru \
--cc=jonathan.derrick@linux.dev \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=nirmal.patel@linux.intel.com \
--cc=robh@kernel.org \
--cc=subtexel@gmail.com \
/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
all inboxes | Powered by JetHome®