All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Patel, Nirmal" <nirmal.patel@linux.intel.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v4] PCI: vmd: Disable bridge window for domain reset
Date: Wed, 9 Aug 2023 22:24:44 -0500	[thread overview]
Message-ID: <20230810032444.GA16254@bhelgaas> (raw)
In-Reply-To: <0b5d53be-e735-496d-3a67-6f965982cef5@linux.intel.com>

On Wed, Aug 09, 2023 at 04:14:06PM -0700, Patel, Nirmal wrote:
> On 8/9/2023 3:00 PM, Bjorn Helgaas wrote:
> > On Wed, Aug 09, 2023 at 05:14:54PM -0400, Nirmal Patel wrote:
> >> During domain reset process vmd_domain_reset() clears PCI
> >> configuration space of VMD root ports. But certain platform
> >> has observed following errors and failed to boot.
> >>   ...
> >>   DMAR: VT-d detected Invalidation Queue Error: Reason f
> >>   DMAR: VT-d detected Invalidation Time-out Error: SID ffff
> >>   DMAR: VT-d detected Invalidation Completion Error: SID ffff
> >>   DMAR: QI HEAD: UNKNOWN qw0 = 0x0, qw1 = 0x0
> >>   DMAR: QI PRIOR: UNKNOWN qw0 = 0x0, qw1 = 0x0
> >>   DMAR: Invalidation Time-out Error (ITE) cleared
> >>
> >> The root cause is that memset_io() clears prefetchable memory base/limit
> >> registers and prefetchable base/limit 32 bits registers sequentially.
> >> This seems to be enabling prefetchable memory if the device disabled
> >> prefetchable memory originally.
> >>
> >> Here is an example (before memset_io()):
> >>
> >>   PCI configuration space for 10000:00:00.0:
> >>   86 80 30 20 06 00 10 00 04 00 04 06 00 00 01 00
> >>   00 00 00 00 00 00 00 00 00 01 01 00 00 00 00 20
> >>   00 00 00 00 01 00 01 00 ff ff ff ff 75 05 00 00
> >>   ...
> >>
> >> So, prefetchable memory is ffffffff00000000-575000fffff, which is
> >> disabled. When memset_io() clears prefetchable base 32 bits register,
> >> the prefetchable memory becomes 0000000000000000-575000fffff, which is
> >> enabled and incorrect.
> > It's not clear to me how this window config causes the VT-d errors.
> > But empirically it seems to be related, and maybe that's enough.
> >
> >> Here is the quote from section 7.5.1.3.9 of PCI Express Base 6.0 spec:
> >>
> >>   The Prefetchable Memory Limit register must be programmed to a smaller
> >>   value than the Prefetchable Memory Base register if there is no
> >>   prefetchable memory on the secondary side of the bridge.
> >>
> >> This is believed to be the reason for the failure and in addition the
> >> sequence of operation in vmd_domain_reset() is not following the PCIe
> >> specs.
> >>
> >> Disable the bridge window by executing a sequence of operations
> >> borrowed from pci_disable_bridge_window() and pci_setup_bridge_io(),
> >> that comply with the PCI specifications.
> >>
> >> Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com>
> >> ---
> >> v3->v4: Following same operation as pci_setup_bridge_io.
> >> v2->v3: Add more information to commit description.
> >> v1->v2: Follow same chain of operation as pci_disable_bridge_window
> >>         and update commit log.
> >> ---
> >>  drivers/pci/controller/vmd.c | 17 +++++++++++++++--
> >>  1 file changed, 15 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> >> index 769eedeb8802..ae5b4c1704e4 100644
> >> --- a/drivers/pci/controller/vmd.c
> >> +++ b/drivers/pci/controller/vmd.c
> >> @@ -526,8 +526,21 @@ static void vmd_domain_reset(struct vmd_dev *vmd)
> >>  				     PCI_CLASS_BRIDGE_PCI))
> >>  					continue;
> >>  
> >> -				memset_io(base + PCI_IO_BASE, 0,
> >> -					  PCI_ROM_ADDRESS1 - PCI_IO_BASE);
> >> +				/* Temporarily disable the I/O range before updating PCI_IO_BASE */
> >> +				writel(0x0000ffff, base + PCI_IO_BASE_UPPER16);
> >> +				/* Update lower 16 bits of I/O base/limit */
> >> +				writew(0x00f0, base + PCI_IO_BASE);
> >> +				/* Update upper 16 bits of I/O base/limit */
> >> +				writel(0, base + PCI_IO_BASE_UPPER16);
> >> +
> >> +				/* MMIO Base/Limit */
> >> +				writel(0x0000fff0, base + PCI_MEMORY_BASE);
> >> +
> >> +				/* Prefetchable MMIO Base/Limit */
> >> +				writel(0, base + PCI_PREF_LIMIT_UPPER32);
> >> +				writel(0x0000fff0, base + PCI_PREF_MEMORY_BASE);
> >> +				writel(0xffffffff, base + PCI_PREF_BASE_UPPER32);
> >> +				writeb(0, base + PCI_CAPABILITY_LIST);
> > What's the purpose of this PCI_CAPABILITY_LIST write?  I guess you
> > don't want to find PM, MSI, MSI-X, PCIe, etc. capabilities?
> >
> > It's been there since the v1 patch, but the commit log only mentions
> > disabling bridge windows.
> 
> I added it since it was part of original memset_io range. However
> from your previous comment, I checked the lspci output for
> PCI_CAPABILITY_LIST with and without the change and it doesn't seem
> to make any difference.

Ah, I see.  My guess is that was a mistake in the original memset_io()
because I don't see a reason to clear PCI_CAPABILITY_LIST.

PCI_CAPABILITY_LIST is HwInit, so should be read-only in terms of
config accesses, and if lspci sees the same capability list before and
after writing a zero to it, it sounds like it *is* read-only.

Bjorn

  reply	other threads:[~2023-08-10  3:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-09 21:14 [PATCH v4] PCI: vmd: Disable bridge window for domain reset Nirmal Patel
2023-08-09 22:00 ` Bjorn Helgaas
2023-08-09 23:14   ` Patel, Nirmal
2023-08-10  3:24     ` Bjorn Helgaas [this message]
2023-08-10 22:09       ` Patel, Nirmal

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=20230810032444.GA16254@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=nirmal.patel@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.