linux-kernel - [Patch v2] KVM: selftests: Test top-down slots event

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240218043003.2424683-1-dapeng1.mi@linux.intel.com>
Date: Sun, 18 Feb 2024 12:30:03 +0800
From: Dapeng Mi <dapeng1.mi@...ux.intel.com>
To: Sean Christopherson <seanjc@...gle.com>,
	Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Kan Liang <kan.liang@...ux.intel.com>,
	Jim Mattson <jmattson@...gle.com>,
	Jinrong Liang <cloudliang@...cent.com>,
	Aaron Lewis <aaronlewis@...gle.com>,
	Dapeng Mi <dapeng1.mi@...el.com>,
	Dapeng Mi <dapeng1.mi@...ux.intel.com>
Subject: [Patch v2] KVM: selftests: Test top-down slots event

Although the fixed counter 3 and its exclusive pseudo slots event are
not supported by KVM yet, the architectural slots event is supported by
KVM and can be programed on any GP counter. Thus add validation for this
architectural slots event.

Top-down slots event "counts the total number of available slots for an
unhalted logical processor, and increments by machine-width of the
narrowest pipeline as employed by the Top-down Microarchitecture
Analysis method."

As for the slot, it's an abstract concept which indicates how many
uops (decoded from instructions) can be processed simultaneously
(per cycle) on HW. In Top-down Microarchitecture Analysis (TMA) method,
the processor is divided into two parts, frond-end and back-end. Assume
there is a processor with classic 5-stage pipeline, fetch, decode,
execute, memory access and register writeback. The former 2 stages
(fetch/decode) are classified to frond-end and the latter 3 stages are
classified to back-end.

In modern Intel processors, a complicated instruction would be decoded
into several uops (micro-operations) and so these uops can be processed
simultaneously and then improve the performance. Thus, assume a
processor can decode and dispatch 4 uops in front-end and execute 4 uops
in back-end simultaneously (per-cycle), so the machine-width of this
processor is 4 and this processor has 4 topdown slots per-cycle.

If a slot is spare and can be used to process a new upcoming uop, then
the slot is available, but if a uop occupies a slot for several cycles
and can't be retired (maybe blocked by memory access), then this slot is
stall and unavailable.

Considering the testing instruction sequence can't be macro-fused on x86
platforms, the measured slots count should not be less than
NUM_INSNS_RETIRED. Thus assert the slots count against NUM_INSNS_RETIRED.

pmu_counters_test passed with this patch on Intel Sapphire Rapids.

About the more information about TMA method, please refer the below link.
https://www.intel.com/content/www/us/en/docs/vtune-profiler/cookbook/2023-0/top-down-microarchitecture-analysis-method.html

Signed-off-by: Dapeng Mi <dapeng1.mi@...ux.intel.com>
---
 tools/testing/selftests/kvm/x86_64/pmu_counters_test.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c b/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
index ae5f6042f1e8..29609b52f8fa 100644
--- a/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
+++ b/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
@@ -119,6 +119,9 @@ static void guest_assert_event_count(uint8_t idx,
 	case INTEL_ARCH_REFERENCE_CYCLES_INDEX:
 		GUEST_ASSERT_NE(count, 0);
 		break;
+	case INTEL_ARCH_TOPDOWN_SLOTS_INDEX:
+		GUEST_ASSERT(count >= NUM_INSNS_RETIRED);
+		break;
 	default:
 		break;
 	}

base-commit: f0f3b810edda57f317d79f452056786257089667
-- 
2.40.1