qemu-arm
[Top][All Lists]
Advanced

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

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


From: Peter Maydell
Subject: Re: [Qemu-arm] [PATCH v4] target/arm: generate a custom MIDR for -cpu max
Date: Fri, 26 Jul 2019 11:30:59 +0100

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...

thanks
-- PMM



reply via email to

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