Commit Graph

5 Commits

Author SHA1 Message Date
Peter Maydell 218fe5ce40 hw/misc/tz-mpc: Zero the LUT on initialization, not just reset
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.

Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Thomas Huth <thuth@redhat.com>
Message-id: 20180724153616.32352-1-peter.maydell@linaro.org
2018-07-30 14:52:15 +01:00
Peter Maydell dd29d0687d hw/misc/tz_mpc.c: Honour the BLK_LUT settings in translate
The final part of the Memory Protection Controller we need to
implement is actually using the BLK_LUT data programmed by the
guest to determine whether to block the transaction or not.

Since this means we now change transaction mappings when
the guest writes to BLK_LUT, we must also call the IOMMU
notifiers at that point.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20180620132032.28865-5-peter.maydell@linaro.org
2018-06-22 13:28:40 +01:00
Peter Maydell 57c49a6e87 hw/misc/tz-mpc.c: Implement correct blocked-access behaviour
The MPC is guest-configurable for whether blocked accesses:
 * should be RAZ/WI or cause a bus error
 * should generate an interrupt or not

Implement this behaviour in the blocked-access handlers.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20180620132032.28865-4-peter.maydell@linaro.org
2018-06-22 13:28:40 +01:00
Peter Maydell cdb6099818 hw/misc/tz-mpc.c: Implement registers
Implement the missing registers for the TZ MPC.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20180620132032.28865-3-peter.maydell@linaro.org
2018-06-22 13:28:39 +01:00
Peter Maydell 344f4b1581 hw/misc/tz-mpc.c: Implement the Arm TrustZone Memory Protection Controller
Implement the Arm TrustZone Memory Protection Controller, which sits
in front of RAM and allows secure software to configure it to either
pass through or reject transactions.

We implement the MPC as a QEMU IOMMU, which will direct transactions
either through to the devices and memory behind it or to a special
"never works" AddressSpace if they are blocked.

This initial commit implements the skeleton of the device:
 * it always permits accesses
 * it doesn't implement most of the registers
 * it doesn't implement the interrupt or other behaviour
   for blocked transactions

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20180620132032.28865-2-peter.maydell@linaro.org
2018-06-22 13:28:39 +01:00