Skip to content
Snippets Groups Projects
  1. Sep 16, 2023
  2. Sep 15, 2023
  3. Sep 07, 2023
  4. Aug 31, 2023
  5. Aug 29, 2023
  6. Aug 24, 2023
  7. Aug 10, 2023
  8. Aug 06, 2023
  9. Aug 05, 2023
  10. Jul 31, 2023
  11. Jul 24, 2023
  12. Jul 23, 2023
  13. Jul 17, 2023
    • Peter Maydell's avatar
      accel/tcg: Zero-pad PC in TCG CPU exec trace lines · e60a7d0d
      Peter Maydell authored
      
      In commit f0a08b09 we changed the type of the PC from
      target_ulong to vaddr.  In doing so we inadvertently dropped the
      zero-padding on the PC in trace lines (the second item inside the []
      in these lines).  They used to look like this on AArch64, for
      instance:
      
      Trace 0: 0x7f2260000100 [00000000/0000000040000000/00000061/ff200000]
      
      and now they look like this:
      Trace 0: 0x7f4f50000100 [00000000/40000000/00000061/ff200000]
      
      and if the PC happens to be somewhere low like 0x5000
      then the field is shown as /5000/.
      
      This is because TARGET_FMT_lx is a "%08x" or "%016x" specifier,
      depending on TARGET_LONG_SIZE, whereas VADDR_PRIx is just PRIx64
      with no width specifier.
      
      Restore the zero-padding by adding an 016 width specifier to
      this tracing and a couple of others that were similarly recently
      changed to use VADDR_PRIx without a width specifier.
      
      We can't unfortunately restore the "32-bit guests are padded to
      8 hex digits and 64-bit guests to 16 hex digits" behaviour so
      easily.
      
      Fixes: f0a08b09 ("accel/tcg/cpu-exec.c: Widen pc to vaddr")
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
      Reviewed-by: default avatarAnton Johansson <anjo@rev.ng>
      Message-id: 20230711165434.4123674-1-peter.maydell@linaro.org
      e60a7d0d
  14. Jul 15, 2023
  15. Jul 03, 2023
    • Alex Bennée's avatar
      plugins: force slow path when plugins instrument memory ops · 6d03226b
      Alex Bennée authored
      
      The lack of SVE memory instrumentation has been an omission in plugin
      handling since it was introduced. Fortunately we can utilise the
      probe_* functions to force all all memory access to follow the slow
      path. We do this by checking the access type and presence of plugin
      memory callbacks and if set return the TLB_MMIO flag.
      
      We have to jump through a few hoops in user mode to re-use the flag
      but it was the desired effect:
      
       ./qemu-system-aarch64 -display none -serial mon:stdio \
         -M virt -cpu max -semihosting-config enable=on \
         -kernel ./tests/tcg/aarch64-softmmu/memory-sve \
         -plugin ./contrib/plugins/libexeclog.so,ifilter=st1w,afilter=0x40001808 -d plugin
      
      gives (disas doesn't currently understand st1w):
      
        0, 0x40001808, 0xe54342a0, ".byte 0xa0, 0x42, 0x43, 0xe5", store, 0x40213010, RAM, store, 0x40213014, RAM, store, 0x40213018, RAM
      
      And for user-mode:
      
        ./qemu-aarch64 \
          -plugin contrib/plugins/libexeclog.so,afilter=0x4007c0 \
          -d plugin \
          ./tests/tcg/aarch64-linux-user/sha512-sve
      
      gives:
      
        1..10
        ok 1 - do_test(&tests[i])
        0, 0x4007c0, 0xa4004b80, ".byte 0x80, 0x4b, 0x00, 0xa4", load, 0x5500800370, load, 0x5500800371, load, 0x5500800372, load, 0x5500800373, load, 0x5500800374, load, 0x5500800375, load, 0x5500800376, load, 0x5500800377, load, 0x5500800378, load, 0x5500800379, load, 0x550080037a, load, 0x550080037b, load, 0x550080037c, load, 0x550080037d, load, 0x550080037e, load, 0x550080037f, load, 0x5500800380, load, 0x5500800381, load, 0x5500800382, load, 0x5500800383, load, 0x5500800384, load, 0x5500800385, load, 0x5500800386, lo
        ad, 0x5500800387, load, 0x5500800388, load, 0x5500800389, load, 0x550080038a, load, 0x550080038b, load, 0x550080038c, load, 0x550080038d, load, 0x550080038e, load, 0x550080038f, load, 0x5500800390, load, 0x5500800391, load, 0x5500800392, load, 0x5500800393, load, 0x5500800394, load, 0x5500800395, load, 0x5500800396, load, 0x5500800397, load, 0x5500800398, load, 0x5500800399, load, 0x550080039a, load, 0x550080039b, load, 0x550080039c, load, 0x550080039d, load, 0x550080039e, load, 0x550080039f, load, 0x55008003a0, load, 0x55008003a1, load, 0x55008003a2, load, 0x55008003a3, load, 0x55008003a4, load, 0x55008003a5, load, 0x55008003a6, load, 0x55008003a7, load, 0x55008003a8, load, 0x55008003a9, load, 0x55008003aa, load, 0x55008003ab, load, 0x55008003ac, load, 0x55008003ad, load, 0x55008003ae, load, 0x55008003af
      
      (4007c0 is the ld1b in the sha512-sve)
      
      Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Cc: Robert Henry <robhenry@microsoft.com>
      Cc: Aaron Lindsay <aaron@os.amperecomputing.com>
      Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Message-Id: <20230630180423.558337-20-alex.bennee@linaro.org>
      6d03226b
  16. Jul 01, 2023
Loading