Re: [PATCH 2/5] KVM: selftests: Only validate counts for hardware-supported arch events

From: Paolo Bonzini
Date: Mon Jan 20 2025 - 11:12:24 EST


On 1/18/25 01:39, Sean Christopherson wrote:
On Sat, Jan 18, 2025, Mingwei Zhang wrote:
On Fri, Jan 17, 2025, Sean Christopherson wrote:
@@ -582,18 +585,26 @@ static void test_intel_counters(void)
/*
* Detect the existence of events that aren't supported by selftests.
- * This will (obviously) fail any time the kernel adds support for a
- * new event, but it's worth paying that price to keep the test fresh.
+ * This will (obviously) fail any time hardware adds support for a new
+ * event, but it's worth paying that price to keep the test fresh.
*/
TEST_ASSERT(nr_arch_events <= NR_INTEL_ARCH_EVENTS,
"New architectural event(s) detected; please update this test (length = %u, mask = %x)",
- nr_arch_events, kvm_cpu_property(X86_PROPERTY_PMU_EVENTS_MASK));
+ nr_arch_events, this_cpu_property(X86_PROPERTY_PMU_EVENTS_MASK));

This is where it would make troubles for us (all companies that might be
using the selftest in upstream kernel and having a new hardware). In
this case when we get new hardware, the test will fail in the downstream
kernel. We will have to wait until the fix is ready, and backport it
downstream, re-test it.... It takes lots of extra work.

If Intel can't upstream what should be a *very* simple patch to enumerate the
new encoding and its expected count in advance of hardware being shipped to
partners, then we have bigger problems.

Conceptually I have bigger problems with people running stable kernels than people running on really really new hardware.

However the intersection of running a pretty old kernel on a very new bare metal x86 system is relatively small but nonzero (those pesky Debian users); it may happen with cloud instances but then the intersection of running old selftests in a nested virt environment is probably even smaller.

I am not too happy about the assertion, but it does seem like the lesser evil.

Paolo