From: Priyank Rathod <rathodpriyank@google.com>
To: Daniel Pereira <danielmaraboo@gmail.com>
Cc: bhelgaas@google.com, lukas@wunner.de,
sathyanarayanan.kuppuswamy@linux.intel.com,
ilpo.jarvinen@linux.intel.com, dave.jiang@intel.com,
prarit@redhat.com, ying.huang@linux.alibaba.com,
terry.bowman@amd.com, corbet@lwn.net, jic23@kernel.org,
linux-doc@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] Documentation: PCI: Document aer_inject's aer_mask_override parameter
Date: Mon, 26 Oct 2026 17:57:24 +0000 [thread overview]
Message-ID: <20261026175724.1482083-1-rathodpriyank@google.com> (raw)
In-Reply-To: <CAMAsx6dLGdqr+ZxG8FrwN-6r=5yVY8hk-c+7CVrAkS0zpKPmGg@mail.gmail.com>
Hi Daniel,
Thank you for reviewing the series and verifying the documentation build
against the implementation!
On Sun, Oct 25, 2026 at 11:19:28AM -0300, Daniel Pereira wrote:
> There is one thing I could not reconcile, in case it is useful. The
> text gives Poisoned TLP Egress Blocked as an example of an error that
> is masked by default. In the sample session of the cover letter,
> PCI_ERR_UNCOR_MASK of the e1000e reads 02400000 before the test, which
> is PCI_ERR_UNC_INTN (0x00400000) plus PCI_ERR_UNC_TLPPRE (0x02000000),
> while PCI_ERR_UNC_POISON_BLK (0x04000000) is clear. The vendor register
> descriptions I found also list that bit with a reset value of 0. The
> Correctable side does match: 0000c000 has Corrected Internal and Header
> Log Overflow set. Internal errors match too, since
> pci_aer_unmask_internal_errors() is only used for CXL.
>
> Perhaps the example could name only errors whose default is confirmed,
> for instance Header Log Overflow and the Internal Errors, or cite the
> spec section if it does say that Poisoned TLP Egress Blocked is masked
> by default. I may well be missing something in the spec.
Per PCIe r7.0, sec 7.8.4.3, Table 7-149, "Uncorrectable Error Mask
Register (Offset 08h)", bit 26 (Poisoned TLP Egress Blocked Mask) has a
default value of 1b (RWS), alongside bit 22 (Uncorrectable Internal
Error Mask, default 1b).
The reason bit 26 reads 0b on the e1000e Endpoint in the cover letter
is Note 3 of Table 7-149: a non-VF Function only implements bit 26 when
Poisoned TLP Egress Blocking Supported is Set in the DPC Capability
Register (Offset 04h, bit 6; PCIe r7.0, sec 7.9.14.2, Table 7-280).
Per PCIe r7.0, sec 7.9.14, the DPC Extended Capability (001Dh) is only
applicable to Root Ports and Switch Downstream Ports, not to Endpoints
like e1000e (and in QEMU, pcie_aer_init() initializes PCI_ERR_UNCOR_MASK
to PCI_ERR_UNC_INTN | PCI_ERR_UNC_TLPPRE = 0x02400000). Per sec 7.8.4.3,
"Register fields for bits not implemented by the Function are hardwired
to 0b."
That said, your suggestion to use "Header Log Overflow or Internal
Errors" (PCIe r7.0, sec 7.8.4.6, Table 7-152, bits 14-15, and
sec 7.8.4.3, Table 7-149, bit 22) as the example is much clearer
because those bits apply to Endpoints as well and match the sample
output directly. If you or anyone else suggests the same, I will gladly
change it.
Thanks,
Priyank
next prev parent reply other threads:[~2026-10-26 17:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 20:53 [PATCH 0/2] PCI/AER: Fix and document aer_inject's aer_mask_override Priyank Rathod
2026-10-12 20:53 ` [PATCH 1/2] PCI/AER: Make aer_mask_override effective for injected errors Priyank Rathod
2026-10-27 23:08 ` Bjorn Helgaas
2026-10-28 17:30 ` Priyank Rathod
2026-10-12 20:53 ` [PATCH 2/2] Documentation: PCI: Document aer_inject's aer_mask_override parameter Priyank Rathod
2026-10-25 14:19 ` Daniel Pereira
2026-10-26 17:57 ` Priyank Rathod [this message]
2026-10-27 14:34 ` Daniel Pereira
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=20261026175724.1482083-1-rathodpriyank@google.com \
--to=rathodpriyank@google.com \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=danielmaraboo@gmail.com \
--cc=dave.jiang@intel.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jic23@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=prarit@redhat.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=terry.bowman@amd.com \
--cc=ying.huang@linux.alibaba.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