qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] arm: bump amount of PMU counters to pass SBSA ACS


From: Leif Lindholm
Subject: Re: [PATCH] arm: bump amount of PMU counters to pass SBSA ACS
Date: Thu, 4 Mar 2021 15:25:12 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Thu, Mar 04, 2021 at 15:14:36 +0000, Peter Maydell wrote:
> On Thu, 4 Mar 2021 at 13:53, Leif Lindholm <leif@nuviainc.com> wrote:
> >
> > On Wed, Mar 03, 2021 at 18:06:46 +0000, Peter Maydell wrote:
> > > On Wed, 3 Mar 2021 at 17:48, Leif Lindholm <leif@nuviainc.com> wrote:
> > > > It would be good if we could get 6.0 closer to SBSA compliance.
> > >
> > > How far away are we at the moment ?
> > >
> > > > Would it be worth the effort to make this controllable per cpu model?
> > >
> > > I don't have a strong opinion on whether we should, but if we do then the
> > > right way to implement that would be to have the PMCR reset value
> > > as a reset_pmcr_el0 field in struct ARMCPU (like the existing reset_fpsid,
> > > reset_sctlr, etc) that gets set per-CPU to whatever the CPU's value for
> > > it is; and then instead of using a PMCR_NUM_COUNTERS value,
> > > extract the PMCR.N field when needed. The hardest part would be
> > > going through all the CPU TRMs to find out the correct reset value.
> >
> > That makes sense.
> >
> > I guess we could also phase the transition by using the default value
> > if zero?
> 
> I tend to prefer to avoid that kind of transitional thing, because
> as a project we have a tendency to never complete transitions. The
> PMU stuff only applies to the v7 and v8 cores, and we don't implement
> that many of them, so it's better to just make the effort to find out
> the correct PMCR reset value for them and be done with it.

Understood.

I'll throw this on my never-shrinking pile of things I hope to get
around to at some point.

/
    Leif



reply via email to

[Prev in Thread] Current Thread [Next in Thread]