All of lore.kernel.org
 help / color / mirror / Atom feed
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);
> +		}
> +	}
<...>

  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.