On 24 July 2018 at 16:45, Thomas Huth <[email protected]> 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 <[email protected]>
Thanks; applied to target-arm for 3.0. -- PMM
