From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4BB02C04A68 for ; Sat, 30 Jul 2022 12:47:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233087AbiG3MrU (ORCPT ); Sat, 30 Jul 2022 08:47:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230135AbiG3MrT (ORCPT ); Sat, 30 Jul 2022 08:47:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 692631C10D for ; Sat, 30 Jul 2022 05:47:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D563360C91 for ; Sat, 30 Jul 2022 12:47:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 182F5C433C1; Sat, 30 Jul 2022 12:47:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659185237; bh=kZTc5twSzrccS0agfAec2OpOomKSTPQRxT/mVPO60wA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Kb43IOBhoKvOWa9jWpAyIecz1GLZIl5jXa9pJ40ioImlCZEA2sEoWbS7y4u6Kd+wA 2Ydz1ytvau8wqxktgkb4mWYHD5Mre9NeUUvC2C1H4z42sQGPXxH/d/1qDsN4Bh6viZ 9u5eJSo8AAk8zW/UFlgLQVFHTH5EkXmmyRQSIdSz4DukE4mSQfjVocyAqxn7FFjZLI wN/C3f2MfdRmKGfv9XSH5a7EHRIDDC/5VYaxfxkGxFbs4ICJw84297biVElhKSNr/H NTEuKPNHXwmPG6lrSv7Xf89O4vSMSexyirnN5jlJJWviLywbqJgD2pWNe/hxlTt4p1 uE3GkhBd1M4gw== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oHlsA-00B2Nm-FG; Sat, 30 Jul 2022 13:47:14 +0100 Date: Sat, 30 Jul 2022 13:47:14 +0100 Message-ID: <87sfmiwywd.wl-maz@kernel.org> From: Marc Zyngier To: Ricardo Koller Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, drjones@redhat.com, alexandru.elisei@arm.com, eric.auger@redhat.com, oliver.upton@linux.dev, reijiw@google.com Subject: Re: [kvm-unit-tests PATCH 3/3] arm: pmu: Remove checks for !overflow in chained counters tests In-Reply-To: <20220718154910.3923412-4-ricarkol@google.com> References: <20220718154910.3923412-1-ricarkol@google.com> <20220718154910.3923412-4-ricarkol@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ricarkol@google.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, drjones@redhat.com, alexandru.elisei@arm.com, eric.auger@redhat.com, oliver.upton@linux.dev, reijiw@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Ricardo, On Mon, 18 Jul 2022 16:49:10 +0100, Ricardo Koller wrote: > > A chained event overflowing on the low counter can set the overflow flag > in PMOVS. KVM does not set it, but real HW and the fast-model seem to. > Moreover, the AArch64.IncrementEventCounter() pseudocode in the ARM ARM > (DDI 0487H.a, J1.1.1 "aarch64/debug") also sets the PMOVS bit on > overflow. > > The pmu chain tests fail on bare metal when checking the overflow flag > of the low counter _not_ being set on overflow. Fix by removing the > checks. > > Signed-off-by: Ricardo Koller > --- > arm/pmu.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/arm/pmu.c b/arm/pmu.c > index a7899c3c..4f2c5096 100644 > --- a/arm/pmu.c > +++ b/arm/pmu.c > @@ -581,7 +581,6 @@ static void test_chained_counters(void) > precise_instrs_loop(22, pmu.pmcr_ro | PMU_PMCR_E); > > report(read_regn_el0(pmevcntr, 1) == 1, "CHAIN counter #1 incremented"); > - report(!read_sysreg(pmovsclr_el0), "no overflow recorded for chained incr #1"); > > /* test 64b overflow */ > > @@ -593,7 +592,7 @@ static void test_chained_counters(void) > precise_instrs_loop(22, pmu.pmcr_ro | PMU_PMCR_E); > report_info("overflow reg = 0x%lx", read_sysreg(pmovsclr_el0)); > report(read_regn_el0(pmevcntr, 1) == 2, "CHAIN counter #1 set to 2"); > - report(!read_sysreg(pmovsclr_el0), "no overflow recorded for chained incr #2"); > + report((read_sysreg(pmovsclr_el0) & 0x2) == 0, "no overflow recorded for chained incr #2"); > > write_regn_el0(pmevcntr, 0, PRE_OVERFLOW); > write_regn_el0(pmevcntr, 1, ALL_SET); > @@ -601,7 +600,7 @@ static void test_chained_counters(void) > precise_instrs_loop(22, pmu.pmcr_ro | PMU_PMCR_E); > report_info("overflow reg = 0x%lx", read_sysreg(pmovsclr_el0)); > report(!read_regn_el0(pmevcntr, 1), "CHAIN counter #1 wrapped"); > - report(read_sysreg(pmovsclr_el0) == 0x2, "overflow on chain counter"); > + report(read_sysreg(pmovsclr_el0) & 0x2, "overflow on chain counter"); > } > > static void test_chained_sw_incr(void) > @@ -626,10 +625,10 @@ static void test_chained_sw_incr(void) > for (i = 0; i < 100; i++) > write_sysreg(0x1, pmswinc_el0); > > - report(!read_sysreg(pmovsclr_el0) && (read_regn_el0(pmevcntr, 1) == 1), > - "no overflow and chain counter incremented after 100 SW_INCR/CHAIN"); > + report(read_regn_el0(pmevcntr, 1) == 1, > + "no chain counter incremented after 100 SW_INCR/CHAIN"); > report_info("overflow=0x%lx, #0=%ld #1=%ld", read_sysreg(pmovsclr_el0), > - read_regn_el0(pmevcntr, 0), read_regn_el0(pmevcntr, 1)); > + read_regn_el0(pmevcntr, 0), read_regn_el0(pmevcntr, 1)); > > /* 64b SW_INCR and overflow on CHAIN counter*/ > pmu_reset(); > @@ -644,7 +643,7 @@ static void test_chained_sw_incr(void) > for (i = 0; i < 100; i++) > write_sysreg(0x1, pmswinc_el0); > > - report((read_sysreg(pmovsclr_el0) == 0x2) && > + report((read_sysreg(pmovsclr_el0) & 0x2) && > (read_regn_el0(pmevcntr, 1) == 0) && > (read_regn_el0(pmevcntr, 0) == 84), > "overflow on chain counter and expected values after 100 SW_INCR/CHAIN"); > @@ -727,8 +726,8 @@ static void test_chain_promotion(void) > report_info("MEM_ACCESS counter #0 has value 0x%lx", > read_regn_el0(pmevcntr, 0)); > > - report((read_regn_el0(pmevcntr, 1) == 1) && !read_sysreg(pmovsclr_el0), > - "CHAIN counter enabled: CHAIN counter was incremented and no overflow"); > + report((read_regn_el0(pmevcntr, 1) == 1), > + "CHAIN counter enabled: CHAIN counter was incremented"); > > report_info("CHAIN counter #1 = 0x%lx, overflow=0x%lx", > read_regn_el0(pmevcntr, 1), read_sysreg(pmovsclr_el0)); > @@ -755,8 +754,8 @@ static void test_chain_promotion(void) > report_info("MEM_ACCESS counter #0 has value 0x%lx", > read_regn_el0(pmevcntr, 0)); > > - report((read_regn_el0(pmevcntr, 1) == 1) && !read_sysreg(pmovsclr_el0), > - "32b->64b: CHAIN counter incremented and no overflow"); > + report((read_regn_el0(pmevcntr, 1) == 1), > + "32b->64b: CHAIN counter incremented"); > > report_info("CHAIN counter #1 = 0x%lx, overflow=0x%lx", > read_regn_el0(pmevcntr, 1), read_sysreg(pmovsclr_el0)); I'm looking at fixing KVM to match this (see the binch of hacks at [1]), and still getting a couple of failures in the PMU overflow tests despite my best effort to fix the code: $ ./arm-run arm/pmu.flat --append pmu-overflow-interrupt /usr/bin/qemu-system-aarch64 -nodefaults -machine virt,gic-version=host -accel kvm -cpu host -device virtio-serial-device -device virtconsole,chardev=ctd -chardev testdev,id=ctd -device pci-testdev -display none -serial stdio -kernel arm/pmu.flat --append pmu-overflow-interrupt # -initrd /tmp/tmp.RQ6FmkvXay INFO: PMU version: 0x1 INFO: PMU implementer/ID code: 0x41("A")/0x3 INFO: Implements 6 event counters PASS: pmu: pmu-overflow-interrupt: no overflow interrupt after preset PASS: pmu: pmu-overflow-interrupt: no overflow interrupt after counting INFO: pmu: pmu-overflow-interrupt: overflow=0x0 PASS: pmu: pmu-overflow-interrupt: overflow interrupts expected on #0 and #1 FAIL: pmu: pmu-overflow-interrupt: no overflow interrupt expected on 32b boundary FAIL: pmu: pmu-overflow-interrupt: expect overflow interrupt on odd counter SUMMARY: 5 tests, 2 unexpected failures Looking at the kut code, I'm wondering whether you're still missing a couple of extra fixes such as: diff --git a/arm/pmu.c b/arm/pmu.c index 4f2c5096..e0b9f71a 100644 --- a/arm/pmu.c +++ b/arm/pmu.c @@ -861,8 +861,8 @@ static void test_overflow_interrupt(void) write_regn_el0(pmevcntr, 0, PRE_OVERFLOW); isb(); mem_access_loop(addr, 200, pmu.pmcr_ro | PMU_PMCR_E); - report(expect_interrupts(0), - "no overflow interrupt expected on 32b boundary"); + report(expect_interrupts(1), + "expect overflow interrupt on 32b counter"); /* overflow on odd counter */ pmu_reset_stats(); @@ -870,8 +870,8 @@ static void test_overflow_interrupt(void) write_regn_el0(pmevcntr, 1, ALL_SET); isb(); mem_access_loop(addr, 400, pmu.pmcr_ro | PMU_PMCR_E); - report(expect_interrupts(0x2), - "expect overflow interrupt on odd counter"); + report(expect_interrupts(0x3), + "expect overflow interrupt on even+odd counters"); } #endif With that, all PMU tests pass. Am I missing something? Did you notice these failing on HW? Thanks, M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/pmu-chained -- Without deviation from the norm, progress is not possible.