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: Wed, 28 Mar 2012 16:39:31 +1030	[thread overview]
Message-ID: <87pqbx9rz8.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20120326094054.GA2475@mudshark.cambridge.arm.com>

On Mon, 26 Mar 2012 10:40:54 +0100, Will Deacon <will.deacon@arm.com> wrote:
> [removed some dead email addresses from CC]

Thanks!

> On Fri, Mar 23, 2012 at 11:17:07PM +0000, Rusty Russell wrote:
> > 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.
> 
> The PMU is very tightly coupled with the CPU and it is necessary to know
> exactly which CPU you have so that you can map microarchitectural events to
> their identifiers. This is not discoverable in the architecture [PMUv2
> provides some support for discovering the status of architected events, but
> that is still not enough and is only present on A7 and A15 so far] so that's
> why we probe the CPU instead.

OK.

> Now, if everything was device-tree based then we could simply use a
> different binding for each CPU but since we support perf on non-DT
> platforms, probing the CPU type is the best solution. I would like to avoid
> the probing code if we are initialised from DT, but I've not got round to it
> yet (this would be useful for big.LITTLE).

I'll be interested to see how you encode the mapping of
microarchitectural events to their identifiers here.

> > > 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.
> 
> I'd rather lie to the guest than modify it just to avoid emulating the
> device correctly. Even then, the profiling results wouldn't be especially
> weird -- everything would be 0, which is a lot better than random
> numbers.

Sure, but nowhere as neat an experience as having "no hardware support
available" printed, and nicely defined failure mode :(

When I get back in May, I'll look at how hard it will to be implement
this properly, if noone else does.

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

  parent reply	other threads:[~2012-03-28  6:09 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
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 [this message]
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=87pqbx9rz8.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.