Skip to content

Executing LD1SB + MTE on Arm64 fails an assert

Host environment

  • Operating system: CentOS Linux release 8.5.2111
  • OS/kernel version: 4.18.0-348.el8.x86_64 #1 SMP Tue Oct 19 15:14:17 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
  • Architecture: x86
  • QEMU flavor: qemu-system-aarch64
  • QEMU version: 8.1.3
  • QEMU command line: qemu-system-aarch64 -S -gdb stdio -display none -d unimp -machine virt,acpi=off,secure=on,virtualization=on,highmem=on,compact-highmem=off,highmem-redists=on,highmem-ecam=off,highmem-mmio=off,gic-version=4,iommu=none,default-bus-bypass-iommu=off,ras=off,mte=on,its=on -cpu max,sve512=on,x-rme=off -smp 2 --accel tcg,thread=multi -kernel $executable

Emulated/Virtualized environment

  • Operating system: bare-metal
  • OS/kernel version:
  • Architecture: aarch64

Description of problem

I'm getting

qemu-system-aarch64: ../tcg/tcg-op-gvec.c:91: simd_desc: Assertion `data == sextract32(data, 0, (32 - ((0 + 8) + 2)))' failed.

This is caused by the upper bits of data being set to 1, which violates the condition.

Steps to reproduce

  1. build QEMU with assertions enabled (e.g., configure --enable-debug-tcg).
  2. have a LD1SB f{z25.d}, p3/z, [x14, x9] (binary a5894dd9) instruction in the executed code.
  3. enable mte
  4. Let QEMU execute the ld1sb instruction.

Additional information

image

This issue happens because for ld1sb, nregs=0 in sve.decode:

# SVE contiguous load (scalar plus scalar)
LD_zprr         1010010 .... ..... 010 ... ..... .....    @rprr_load_dt nreg=0 

As a result, in do_mem_zpa is called with n_reg=0, which becomes mte_n inside do_mem_zpa. Since mte_n==0, and mte_active, then

desc = FIELD_DP32(desc, MTEDESC, SIZEM1, (mte_n << msz) - 1);

sets (0) - 1 == -1 to the field, which also sets the upper bits of desc. The desc with upper bits set to 1 is used to call:

desc = simd_desc(vsz, vsz, zt | desc);

Inside simd_desc, the last parameter is named data and it fails the assertion:

tcg_debug_assert(data == sextract32(data, 0, SIMD_DATA_BITS))

similar bug.

I am not sure if this counts as the same bug, but the same assertion fails on sve.decode:1270:

# SVE contiguous non-temporal store (scalar plus scalar)     (nreg == 0)
# SVE store multiple structures (scalar plus scalar)         (nreg != 0)
ST_zprr         1110010 msz:2 nreg:2 ..... 011 ... ..... ..... \
@rprr_store esz=%size_23

Instruction: e5e975f7 st4d {z23.d-z26.d}, p5, [x15, x9, lsl #3]

with the bt:

#3  0x00007fd58ca7fa76 in .annobin_assert.c_end () at /usr/lib64/libc.so.6
#4  0x00005598fc07cb2b in simd_desc (oprsz=oprsz@entry=64, maxsz=maxsz@entry=64, data=data@entry=3024407) at ../tcg/tcg-op-gvec.c:91
#5  0x00005598fbd0c3de in do_mem_zpa                                                                                                          (s=<optimized out>, zt=<optimized out>, pg=5, addr=0x2310, dtype=<optimized out>, mte_n=<optimized out>, is_write=true, fn=0x5598fbcfaa50 <gen_helper_sve_st4dd_le_r_mte>) at ../target/arm/tcg/translate-sve.c:4468
#6  0x00005598fbd0c514 in do_st_zpa  (s=s@entry=0x7fd585ab51f0, zt=<optimized out>, pg=<optimized out>, addr=addr@entry=0x2310, msz=<optimized out>, esz=<optimized out>, nreg=<optimized out>) at ../target/arm/tcg/translate-sve.c:5180
#7  0x00005598fbd127fe in trans_ST_zprr (a=0x7fd585ab5030, s=0x7fd585ab51f0) at ../target/arm/tcg/translate-sve.c:5195
#8  0x00005598fbd127fe in trans_ST_zprr (s=0x7fd585ab51f0, a=0x7fd585ab5030) at ../target/arm/tcg/translate-sve.c:5183
Edited by snps-veksler
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information