Re: [PATCH 2/2] target/arm: Look up ARMCPRegInfo at runtime

[Alex Bennée]

Richard Henderson <richard.henderson@linaro.org> writes:

> On 1/23/23 02:53, Peter Maydell wrote:
>> On Fri, 6 Jan 2023 at 19:45, Richard Henderson
>> <richard.henderson@linaro.org> wrote:
>>>
>>> Do not encode the pointer as a constant in the opcode stream.
>>> This pointer is specific to the cpu that first generated the
>>> translation, which runs into problems with both hot-pluggable
>>> cpus and user-only threads, as cpus are removed.
>>>
>>> Perform the lookup in either helper_access_check_cp_reg,
>>> or a new helper_lookup_cp_reg.
>> As well as the use-after-free, this is also a correctness
>> bug, isn't it? If we hardwire in the cpregs pointer for
>> CPU 0 into the TB, and then CPU 1 with a slightly different
>> config executes the TB, it will get the cpregs of CPU 0,
>> not its own, so it might see a register it should not or
>> vice-versa.
>
> Existing assumption was that each cpu configuration would have its own
> cluster_index, which gets encoded into cpu->tcg_cflags, which is part
> of the comparison used when hashing TBs.

I understand the cluster_index is used for things like A/R and A/M
splits (and eventually heterogeneous). We also have language to cover
the increasingly weird set of big.LITTLE offspring like M1's
Performance/Efficiency split or the Tensor's X1/A76/A55 split.

 * If CPUs are not identical (for example, Cortex-A53 and Cortex-A57 CPUs in an
 * Arm big.LITTLE system) they should be in different clusters. If the CPUs do
 * not have the same view of memory (for example the main CPU and a management
 * controller processor) they should be in different clusters.

> But including this patch allows relaxation of what constitutes a "cpu 
> configuration".
>
>
> r~


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro