1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Alright, so I need to classify this bug report for QEMU. Let's start by understanding the problem.
The user mentioned an assert fail in QEMU related to RISC-V RVV vmv.v.x for e64 when vl equals vl_max on a RV32 guest. The error is in tcg_gen_gvec_dup_i32, where vece is MO_64 but the assertion expects it to be <= MO_32.
Looking at the categories provided: mistranslation, assembly lowering, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
The bug seems to be in the translation of RISC-V instructions, specifically vector operations. The function trans_vmv_v_x is involved, which likely handles generating the machine code for the vmv.v.x instruction. The error occurs during assembly lowering since it's happening in tcg_op_gvec.c and trans_rvv.c.inc, which are parts of QEMU's translation process.
The issue arises because for e64 (which implies 64-bit elements), vece is MO_64, but the function expects a maximum of MO_32. This suggests that the code isn't correctly handling 64-bit vectors on a RV32 guest, leading to a mistranslation during assembly lowering.
The provided solution modifies the translation by checking TARGET_LONG_BITS and using appropriate TCG functions for 64-bit elements when necessary. This adjustment should fix the assert failure.
So, the bug is related to incorrect handling of vector operations during assembly lowering, which points to 'assembly' as the category.
</think>
assembly
|