qemu-devel
[Top][All Lists]
Advanced

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

Re: [PULL 09/11] target/arm: add support for PMUv3 64-bit PMCCNTR in AAr


From: Peter Maydell
Subject: Re: [PULL 09/11] target/arm: add support for PMUv3 64-bit PMCCNTR in AArch32 mode
Date: Mon, 12 Aug 2024 11:30:58 +0100

On Mon, 12 Aug 2024 at 10:39, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Sun, 11 Aug 2024 at 22:36, Richard Henderson
> <richard.henderson@linaro.org> wrote:
> >
> > On 8/10/24 04:08, Peter Maydell wrote:
> > > From: Alex Richardson <alexrichardson@google.com>
> > > diff --git a/target/arm/helper.c b/target/arm/helper.c
> > > index 8fb4b474e83..94900667c33 100644
> > > --- a/target/arm/helper.c
> > > +++ b/target/arm/helper.c
> > > @@ -5952,6 +5952,12 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
> > >         .access = PL1_RW, .accessfn = access_trap_aa32s_el1,
> > >         .writefn = sdcr_write,
> > >         .fieldoffset = offsetoflow32(CPUARMState, cp15.mdcr_el3) },
> > > +    { .name = "PMCCNTR", .state = ARM_CP_STATE_AA32,
> > > +      .type = ARM_CP_ALIAS | ARM_CP_IO | ARM_CP_64BIT,
> > > +      .cp = 15, .crm = 9, .opc1 = 0,
> > > +      .access = PL0_RW, .resetvalue = 0, .fgt = FGT_PMCCNTR_EL0,
> > > +      .readfn = pmccntr_read, .writefn = pmccntr_write,
> > > +      .accessfn = pmreg_access_ccntr },
> > >   };
> > >
> > >   /* These are present only when EL1 supports AArch32 */
> >
> > This fails testing:
> >
> > https://gitlab.com/qemu-project/qemu/-/jobs/7551982466
> >
> > FAIL: duplicate register {'name': 'PMCCNTR', 'regnum': 96} vs {'name': 
> > 'PMCCNTR',
> > 'regnum': 79}
> > FAIL: counted all 219 registers in XML
> > FAIL: PMCCNTR 96 == 79 (xml)
>
> Hmm, not sure why that didn't get caught by my local testing
> or by my gitlab run -- does it only get run on an aarch64 host?
>
> Anyway, the registers do architecturally have the same name
> (they're the same register, just accessible via different
> pathways). What is our practice for this? Do we just give
> one of them a non-standard name?

Looking at how we handle "PAR", we have some clunky code
to add the ARM_CP_NO_GDB flag to the 32-bit version.
I guess that produces the best results but it's going
to be kind of awkward...

-- PMM



reply via email to

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