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