[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4] target/arm: generate a custom MIDR for -cpu
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [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