All of lore.kernel.org
 help / color / mirror / Atom feed
From: rusty@rustcorp.com.au (Rusty Russell)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: test for PMU feature on v7 (v2 with typo fix)
Date: Sat, 24 Mar 2012 09:47:07 +1030	[thread overview]
Message-ID: <87fwcy9abw.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20120323095314.GA13622@mudshark.cambridge.arm.com>

On Fri, 23 Mar 2012 09:53:14 +0000, Will Deacon <will.deacon@arm.com> wrote:
> Hi Rusty,
> 
> On Fri, Mar 23, 2012 at 12:34:57AM +0000, Rusty Russell wrote:
> > The v7 ARM (B4.1.82) specifies that bits 27-24 of the ID_DFR0 reg show
> > what performance monitoring (if any) is available.  We should test this
> > before assuming (useful for inside virtualized environments, for example).
> 
> Ok, I can see why you don't want to emulate a PMU but I don't agree with the
> patch :)
...
> >  static struct arm_pmu *__init armv7_a8_pmu_init(void)
> >  {
> > +	if (!armv7_pmu_avail())
> > +		return NULL;
> 
> This code is only executed if we know for sure that we are running on a
> Cortex-A8. Cortex-A8 implementations have a PMU, so I don't like having the
> probe here in case we are running on a virtualised CPU that doesn't quite
> match the hardware.

OK, I see that argument, but I don't like it.  eg. the Cortex A-15 is
defined to have a PMUv2 with 6 counters, and below you're arguing we
should implement zero of them.

I had assumed that as we trend towards a common cross-platform kernel,
we should be relying on feature registers where available, not the
model.

> Would you be able to advertise 0 event counters instead and treat the PMU
> largely as RAZ/WI? The only tricky bit I can see is the cycle counter, which
> is mandated by the presence of a PMU, however this could also just RAZ
> initially.

Yes, that's the effect of the current emulation hack.  Far better not to
lie to the guest, however, than get weird results from profiling.

Cheers,
Rusty.
-- 
  How could I marry someone with more hair than me?  http://baldalex.org

  reply	other threads:[~2012-03-23 23:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4F590411.9060201@arm.com>
2012-03-23  0:32 ` [PATCH] ARM: test for PMU feature on v7 Rusty Russell
2012-03-23  0:34   ` [PATCH] ARM: test for PMU feature on v7 (v2 with typo fix) Rusty Russell
2012-03-23  9:53     ` Will Deacon
2012-03-23 23:17       ` Rusty Russell [this message]
2012-03-26  9:40         ` Will Deacon
2012-03-26  9:50           ` [Android-virt] " Peter Maydell
2012-03-26 15:15             ` Will Deacon
2012-03-28  6:09           ` Rusty Russell
2012-03-28 14:17           ` Nicolas Pitre
2012-03-30 17:04             ` Will Deacon
2012-03-30 17:40               ` Nicolas Pitre
2012-03-23  0:38   ` [PATCH] ARM: KVM: Emulate ID_DFR0 to say we don't support anything Rusty Russell
2012-03-23  9:04     ` [Android-virt] " Peter Maydell
2012-03-23 23:23       ` Rusty Russell

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=87fwcy9abw.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.