Re: [Qemu-arm] [Qemu-devel] [PATCH for-3.0] hw/misc/tz-mpc: Zero the LUT on initialization, not just reset

[Peter Maydell]

On 24 July 2018 at 16:45, Thomas Huth <address@hidden> wrote:
> On 24.07.2018 17:36, Peter Maydell wrote:
>> In the tz-mpc device we allocate a data block for the LUT,
>> which we then clear to zero in the device's reset method.
>> This is conceptually fine, but unfortunately results in a
>> valgrind complaint about use of uninitialized data on startup:
>>
>> ==30906== Conditional jump or move depends on uninitialised value(s)
>> ==30906==    at 0x503609: tz_mpc_translate (tz-mpc.c:439)
>> ==30906==    by 0x3F3D90: address_space_translate_iommu (exec.c:511)
>> ==30906==    by 0x3F3FF8: flatview_do_translate (exec.c:584)
>> ==30906==    by 0x3F4292: flatview_translate (exec.c:644)
>> ==30906==    by 0x3F2120: address_space_translate (memory.h:1962)
>> ==30906==    by 0x3FB753: address_space_ldl_internal (memory_ldst.inc.c:36)
>> ==30906==    by 0x3FB8A6: address_space_ldl (memory_ldst.inc.c:80)
>> ==30906==    by 0x619037: ldl_phys (memory_ldst_phys.inc.h:25)
>> ==30906==    by 0x61985D: arm_cpu_reset (cpu.c:255)
>> ==30906==    by 0x98791B: cpu_reset (cpu.c:249)
>> ==30906==    by 0x57FFDB: armv7m_reset (armv7m.c:265)
>> ==30906==    by 0x7B1775: qemu_devices_reset (reset.c:69)
>>
>> This is because of a reset ordering problem -- the TZ MPC
>> resets after the CPU, but an M-profile CPU's reset function
>> includes memory loads to get the initial PC and SP, which
>> then go through an MPC that hasn't yet been reset.
>>
>> The simplest fix for this is to zero the LUT when we
>> initialize the data, which will result in the MPC's
>> translate function giving the right answers for these
>> early memory accesses.
>
> Thanks, that fixes the issue, indeed:
>
> Tested-by: Thomas Huth <address@hidden>

Thanks; applied to target-arm for 3.0.

-- PMM