From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B5862366836 for ; Sat, 30 May 2026 21:39:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780177188; cv=none; b=CjDOs0jSClq4b9EKjkwBMB2PJ3YDp00wIM6wUrhLXUEeMhv16WLFWGuJLvtVLduwa5Mcfq6VIe1JR3/lWA1vkRzPU9rMTIXXzeBBP5FI18lcVkn8CpjZN6PlnJC6YUEDZjixWDfh5OQscAIEDwxFjol62eQaD7Rp9VwSRuF7ToQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780177188; c=relaxed/simple; bh=CkAwCQ70kgagdEEU0IM9lUp5FDHJMlhvJgev/qc90gc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bN+oFwPnPkKE1hM30pfXLjXod0aQkuqEAWE7tRPgOrIK1lEq4Exk7eIFjZq5pO/Geh0jrgWZQckA3MpH8uXvkm8gTAgHS+t1+Vr9+KrJM/t9KdQhqHTrPDQ4wauDV3ZX1MfsNh/Q4idUyrzs9jR8eod1WxyeG6m32sLP0MqquxI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=Hbr/kzjj; arc=none smtp.client-ip=209.85.208.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Hbr/kzjj" Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-39677242021so1503761fa.1 for ; Sat, 30 May 2026 14:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1780177185; x=1780781985; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=uHjLm5yZVaqWyJ02pwhoH7CQXdVKY/DTm5HnPQmN1y8=; b=Hbr/kzjjodkX1FZpRfjMFS7+8JL6EwYkeCGFEqazlR4oQ8nThm887w2kEeNCX8Ij+P /OpE6247r7xRfk4TrZs+g0mYAmMheffQdooTrqTq3RfgbjvWB+yW+vhoaklLvkN5svAi BYAaZTKnDdytJkFYzSZWJlymu8cdQ6Gu+Ea20= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780177185; x=1780781985; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uHjLm5yZVaqWyJ02pwhoH7CQXdVKY/DTm5HnPQmN1y8=; b=PoNPqngQvzn9cEhaVHoZ7zQKWPulTNCNsKXpV+at9JQ9M0T6jXh45o41C1ozwYEFCW L5S7muUdb0yYcqNpaMYmOqH7I5L4rqaI2Ru7BV/1rsMGXgUaJF5kKO4lbTLqDTe31iBX WWxJ4xBXRykpreCdgYFaE0fmS18AM58390QzTBtntQpmMTdJDCdMMsKep+EPq/A+1ZPW xMG6gyT2KEi9fDywiHMwqXTsbtstIZCbmmA/MnRKGQ1y2Qq7hnVH0WXG/PemYXs8Bgsz E2JnNYc6Sy/e/drFUXE4RNoW6bR3VsUry+H3eMc+Gq0J4rCvKrJSd6K5m6okW5xm1tkw dw3A== X-Forwarded-Encrypted: i=1; AFNElJ+6tVXwr+3Z7N0+ahIncz669fnCp/Nv9oljAMRzgmzOdsBl7MxWKCq0ACb+/XNoPLKQ5CI2BAz09KEevFs=@vger.kernel.org X-Gm-Message-State: AOJu0YwBtjmNnjVi0GjHI7fPJ76HGJ2YZorLp5dADjYmCWakhiyjWKgJ Ac/ApXADtQvx6SU40pdcBZuiKSytQ4xP8mFfkrfihXFbJQACBttP6sjj03aCntS2hA== X-Gm-Gg: Acq92OFdBimDVTU+Qz75lXruwXo1xS9iQCxNDpx2KoAaGLr9oMJNTe/LtxCGe9iqmq9 96LLXC90z9pj2VZR/TaDvIKjrntGKuMKMIXqbtom6YIbOOxmzOc8Oi4vVMt/xi2fONofTixnF5g G2T0K0nzwxAXsYRZSnjzDe1rkNS+q9/9qXVVOjzcWvfkctRjzXiXya53HwpuOt+kBvDcCl2TKqX 6au2H35qiD7jBTYvipcUKOFnv3eooSzD/NzdI4z2CR9PKAs6XZXlbM/LwV/Lsje0jScKcCG2vhp rhw5zp+bbu/1hU8bj/lCVdNwUacfMQOChoY0eUyJeBYka+Il8iQ3PK0MphkxJ5LsmZXskayg5tL uCwzCFHJu0TPewfBSbMpSrNeJQlsrPpwUuez1ipW5Czl6BwBthVEsbE3OltuXonakg1/Zn06ROK pmLR+sQBnalyaTg+eqzbH7rdTf/wDgKbsbFxG8 X-Received: by 2002:a05:651c:1198:b0:393:e571:277a with SMTP id 38308e7fff4ca-39664f0be9bmr10766131fa.9.1780177184987; Sat, 30 May 2026 14:39:44 -0700 (PDT) Received: from google.com ([2a02:a31b:20c3:6680:a425:7ae:4d82:6214]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-39661e708ddsm9882101fa.22.2026.05.30.14.39.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 May 2026 14:39:43 -0700 (PDT) Date: Sat, 30 May 2026 23:39:34 +0200 From: Dmytro Maluka 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 Message-ID: References: <20230128200428.1459118-1-kan.liang@linux.intel.com> <20230128200428.1459118-3-kan.liang@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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); > + } > + } <...>