All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ricardo Koller <ricarkol@google.com>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	andrew.jones@linux.dev, maz@kernel.org, alexandru.elisei@arm.com,
	eric.auger@redhat.com, reijiw@google.com
Subject: Re: [kvm-unit-tests PATCH v2 1/4] arm: pmu: Fix overflow checks for PMUv3p5 long counters
Date: Mon, 9 Jan 2023 08:10:35 -0800	[thread overview]
Message-ID: <Y7w8e27/PXbjw153@google.com> (raw)
In-Reply-To: <Y7h2eQp5oFd/DN7A@google.com>

On Fri, Jan 06, 2023 at 07:28:57PM +0000, Oliver Upton wrote:
> Hi Ricardo,
> 
> On Tue, Dec 20, 2022 at 03:10:29AM +0000, Ricardo Koller wrote:
> > PMUv3p5 uses 64-bit counters irrespective of whether the PMU is configured
> > for overflowing at 32 or 64-bits. The consequence is that tests that check
> > the counter values after overflowing should not assume that values will be
> > wrapped around 32-bits: they overflow into the other half of the 64-bit
> > counters on PMUv3p5.
> > 
> > Fix tests by correctly checking overflowing-counters against the expected
> > 64-bit value.
> > 
> > Signed-off-by: Ricardo Koller <ricarkol@google.com>
> > ---
> >  arm/pmu.c | 37 +++++++++++++++++++++++++------------
> >  1 file changed, 25 insertions(+), 12 deletions(-)
> > 
> > diff --git a/arm/pmu.c b/arm/pmu.c
> > index cd47b14..1b55e20 100644
> > --- a/arm/pmu.c
> > +++ b/arm/pmu.c
> > @@ -54,10 +54,13 @@
> >  #define EXT_COMMON_EVENTS_LOW	0x4000
> >  #define EXT_COMMON_EVENTS_HIGH	0x403F
> >  
> > -#define ALL_SET			0xFFFFFFFF
> > -#define ALL_CLEAR		0x0
> > -#define PRE_OVERFLOW		0xFFFFFFF0
> > -#define PRE_OVERFLOW2		0xFFFFFFDC
> > +#define ALL_SET			0x00000000FFFFFFFFULL
> > +#define ALL_SET_64		0xFFFFFFFFFFFFFFFFULL
> > +#define ALL_CLEAR		0x0000000000000000ULL
> > +#define PRE_OVERFLOW		0x00000000FFFFFFF0ULL
> > +#define PRE_OVERFLOW2		0x00000000FFFFFFDCULL
> > +
> > +#define ALL_SET_AT(_64b)       (_64b ? ALL_SET_64 : ALL_SET)
> 
> AFAICT, ALL_SET is mostly used to toggle all PMCs in a configuration
> register. 

It's also used as a pre-overflow counter value. And that's mainly the use of
the newly introduced ALL_SET_AT(), and PRE_OVERFLOW_AT(). The ALL_SET_AT()
changes in this commit should be moved to commit 3; I will do that plus use
pmevcntr_mask() instead of ALL_SET_AT():

	uint64_t all_set = pmevcntr_mask();
	...
	/* overflow on odd counter */
	write_regn_el0(pmevcntr, 0, pre_overflow);
	write_regn_el0(pmevcntr, 1, all_set);


> Using it for PMEVCNTR<n> seems a bit odd to me. How about
> introducing a helper for getting the counter mask to avoid the
> open-coded version check?
> 
> static uint64_t pmevcntr_mask(void)
> {
> 	/*
> 	 * Bits [63:0] are always incremented for 64-bit counters,
> 	 * even if the PMU is configured to generate an overflow at
> 	 * bits [31:0]
> 	 *
> 	 * See DDI0487I.a, section D11.3 ("Behavior on overflow") for
> 	 * more details.
> 	 */
> 	if (pmu.version >= ID_DFR0_PMU_V3_8_5)
> 		return ~0;
> 
> 	return (uint32_t)~0;
> }
> 
> I've always found the PMU documentation to be a bit difficult to grok,
> and the above citation only mentions the intended behavior in passing.
> Please feel free to update with a better citation if it exists.
> 
> >  #define PMU_PPI			23
> >  
> > @@ -538,6 +541,7 @@ static void test_mem_access(void)
> >  static void test_sw_incr(void)
> >  {
> >  	uint32_t events[] = {SW_INCR, SW_INCR};
> > +	uint64_t cntr0;
> >  	int i;
> >  
> >  	if (!satisfy_prerequisites(events, ARRAY_SIZE(events)))
> > @@ -572,9 +576,11 @@ static void test_sw_incr(void)
> >  		write_sysreg(0x3, pmswinc_el0);
> >  
> >  	isb();
> > -	report(read_regn_el0(pmevcntr, 0)  == 84, "counter #1 after + 100 SW_INCR");
> > -	report(read_regn_el0(pmevcntr, 1)  == 100,
> > -		"counter #0 after + 100 SW_INCR");
> > +	cntr0 = (pmu.version < ID_DFR0_PMU_V3_8_5) ?
> > +		(uint32_t)PRE_OVERFLOW + 100 :
> > +		(uint64_t)PRE_OVERFLOW + 100;
> 
> With the above suggestion, it would be nice to rewrite like so:
> 
> 	cntr0 = (PRE_OVERFLOW + 100) & pmevcntr_mask();
> 
> If you do go this route, then you'll probably want to drop all the other
> open-coded PMUv3p5 checks in favor of the helper.

Will also use this instead of the uintxx_t casting.

Thanks~
Ricardo

> 
> --
> Thanks,
> Oliver

  reply	other threads:[~2023-01-09 16:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20  3:10 [kvm-unit-tests PATCH v2 0/4] arm: pmu: Add support for PMUv3p5 Ricardo Koller
2022-12-20  3:10 ` Ricardo Koller
2022-12-20  3:10 ` [kvm-unit-tests PATCH v2 1/4] arm: pmu: Fix overflow checks for PMUv3p5 long counters Ricardo Koller
2022-12-20  3:10   ` Ricardo Koller
2023-01-06 19:28   ` Oliver Upton
2023-01-09 16:10     ` Ricardo Koller [this message]
2023-01-09 20:32     ` Ricardo Koller
2022-12-20  3:10 ` [kvm-unit-tests PATCH v2 2/4] arm: pmu: Prepare for testing 64-bit overflows Ricardo Koller
2022-12-20  3:10   ` Ricardo Koller
2022-12-20  3:10 ` [kvm-unit-tests PATCH v2 3/4] arm: pmu: Add tests for " Ricardo Koller
2022-12-20  3:10   ` Ricardo Koller
2022-12-20  3:10 ` [kvm-unit-tests PATCH v2 4/4] arm: pmu: Print counter values as hexadecimals Ricardo Koller
2022-12-20  3:10   ` Ricardo Koller

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=Y7w8e27/PXbjw153@google.com \
    --to=ricarkol@google.com \
    --cc=alexandru.elisei@arm.com \
    --cc=andrew.jones@linux.dev \
    --cc=eric.auger@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=reijiw@google.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.