From: Dmytro Maluka <dmaluka@chromium.org>
To: kan.liang@linux.intel.com
Cc: joro@8bytes.org, will@kernel.org, baolu.lu@linux.intel.com,
dwmw2@infradead.org, robin.murphy@arm.com,
robert.moore@intel.com, rafael.j.wysocki@intel.com,
lenb@kernel.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, yu-cheng.yu@intel.com,
vineeth@bitbyteword.org, aashish@aashishsharma.net,
jaszczyk@chromium.org
Subject: Re: [PATCH V4 2/7] iommu/vt-d: Retrieve IOMMU perfmon capability information
Date: Sat, 30 May 2026 23:39:34 +0200 [thread overview]
Message-ID: <ahtZFmndygWdQU3r@google.com> (raw)
In-Reply-To: <20230128200428.1459118-3-kan.liang@linux.intel.com>
Sorry for the late reply, I've just stumbled upon this code and a few
things look confusing to me:
On Sat, Jan 28, 2023 at 12:04:23PM -0800, kan.liang@linux.intel.com wrote:
<...>
> + /*
> + * Check per-counter capabilities. All counters should have the
> + * same capabilities on Interrupt on Overflow Support and Counter
> + * Width.
> + */
> + for (i = 0; i < iommu_pmu->num_cntr; i++) {
> + cap = dmar_readl(iommu_pmu->cfg_reg +
> + i * IOMMU_PMU_CFG_OFFSET +
> + IOMMU_PMU_CFG_CNTRCAP_OFFSET);
> + if (!iommu_cntrcap_pcc(cap))
> + continue;
> +
> + /*
> + * It's possible that some counters have a different
> + * capability because of e.g., HW bug. Check the corner
> + * case here and simply drop those counters.
> + */
> + if ((iommu_cntrcap_cw(cap) != iommu_pmu->cntr_width) ||
> + !iommu_cntrcap_ios(cap)) {
> + iommu_pmu->num_cntr = i;
> + pr_warn("PMU counter capability inconsistent, counter number reduced to %d\n",
> + iommu_pmu->num_cntr);
1. AFAICS according to the VT-d spec section 11.4.13.2 (about the global
Counter Width in the PERFCAP register): "If per-counter capabilities are
supported, the counter width indicated in the PERFCNTRCAP registers
overrides this value."
which, I'd assume, means that a per-counter Counter Width is allowed
to be different from the global one (i.e. it is not necessarily a HW
bug)?
2. By truncating the number of counters here, we disregard all
subsequent counters, including possibly valid ones (which would pass
this check)?
3. If we disregard all subsequent counters anyway, why don't we break
from the loop here?
> + }
> +
> + /* Clear the pre-defined events group */
> + for (j = 0; j < iommu_pmu->num_eg; j++)
> + iommu_pmu->cntr_evcap[i][j] = 0;
> +
> + /* Override with per-counter event capabilities */
> + for (j = 0; j < iommu_cntrcap_egcnt(cap); j++) {
> + cap = dmar_readl(iommu_pmu->cfg_reg + i * IOMMU_PMU_CFG_OFFSET +
> + IOMMU_PMU_CFG_CNTREVCAP_OFFSET +
> + (j * IOMMU_PMU_OFF_REGS_STEP));
> + iommu_pmu->cntr_evcap[i][iommu_event_group(cap)] = iommu_event_select(cap);
> + /*
> + * Some events may only be supported by a specific counter.
> + * Track them in the evcap as well.
> + */
> + iommu_pmu->evcap[iommu_event_group(cap)] |= iommu_event_select(cap);
> + }
> + }
<...>
next prev parent reply other threads:[~2026-05-30 21:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-28 20:04 [PATCH V4 0/7] iommu/vt-d: Support performance monitoring for IOMMU kan.liang
2023-01-28 20:04 ` [PATCH V4 1/7] iommu/vt-d: Support size of the register set in DRHD kan.liang
2023-01-28 20:04 ` [PATCH V4 2/7] iommu/vt-d: Retrieve IOMMU perfmon capability information kan.liang
2026-05-30 21:39 ` Dmytro Maluka [this message]
2023-01-28 20:04 ` [PATCH V4 3/7] iommu/vt-d: Support Enhanced Command Interface kan.liang
2023-01-28 20:04 ` [PATCH V4 4/7] iommu/vt-d: Add IOMMU perfmon support kan.liang
2023-01-28 20:04 ` [PATCH V4 5/7] iommu/vt-d: Support cpumask for IOMMU perfmon kan.liang
2023-01-28 20:04 ` [PATCH V4 6/7] iommu/vt-d: Add IOMMU perfmon overflow handler support kan.liang
2023-01-28 20:04 ` [PATCH V4 7/7] iommu/vt-d: Enable IOMMU perfmon support kan.liang
2023-01-31 7:54 ` [PATCH V4 0/7] iommu/vt-d: Support performance monitoring for IOMMU Baolu Lu
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=ahtZFmndygWdQU3r@google.com \
--to=dmaluka@chromium.org \
--cc=aashish@aashishsharma.net \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jaszczyk@chromium.org \
--cc=joro@8bytes.org \
--cc=kan.liang@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@intel.com \
--cc=robin.murphy@arm.com \
--cc=vineeth@bitbyteword.org \
--cc=will@kernel.org \
--cc=yu-cheng.yu@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.