Re: [Qemu-devel] [PATCH v4] target/arm: generate a custom MIDR for -cpu max

[Peter Maydell]

On Fri, 26 Jul 2019 at 11:30, Peter Maydell <address@hidden> wrote:
>
> On Fri, 26 Jul 2019 at 11:30, Alex Bennée <address@hidden> wrote:
> >
> > While most features are now detected by probing the ID_* registers
> > kernels can (and do) use MIDR_EL1 for working out of they have to
> > apply errata. This can trip up warnings in the kernel as it tries to
> > work out if it should apply workarounds to features that don't
> > actually exist in the reported CPU type.
> >
> > Avoid this problem by synthesising our own MIDR value.
> >
> > Signed-off-by: Alex Bennée <address@hidden>
> > Reviewed-by: Peter Maydell <address@hidden>
>
> > +        /*
> > +         * Reset MIDR so the guest doesn't mistake our 'max' CPU type for 
> > a real
> > +         * one and try to apply errata workarounds or use impdef features 
> > we
> > +         * don't provide.
> > +         * An IMPLEMENTER field of 0 means "reserved for software use";
> > +         * ARCHITECTURE must be 0xf indicating "v7 or later, check ID 
> > registers
> > +         * to see which features are present";
> > +         * the VARIANT, PARTNUM and REVISION fields are all implementation
> > +         * defined and we choose to define VARIANT and set the others to 
> > zero.
> > +         */
> > +        t = FIELD_DP64(0, MIDR_EL1, IMPLEMENTER, 0);
> > +        t = FIELD_DP64(t, MIDR_EL1, ARCHITECTURE, 0xf);
> > +        t = FIELD_DP64(t, MIDR_EL1, PARTNUM, 'Q');
> > +        t = FIELD_DP64(t, MIDR_EL1, VARIANT, 0);
> > +        t = FIELD_DP64(t, MIDR_EL1, REVISION, 0);
>
> Comment still says we set VARIANT but code says we set PARTNUM...

I guess we might also briefly mention why we set PARTNUM
("just in case guest code needs to distinguish this QEMU CPU from
other software implementations, though this shouldn't be needed",
or some such.)

thanks
-- PMM