diff options
Diffstat (limited to 'results/classifier/semantic-bugs/1926759')
| -rw-r--r-- | results/classifier/semantic-bugs/1926759 | 57 |
1 files changed, 2 insertions, 55 deletions
diff --git a/results/classifier/semantic-bugs/1926759 b/results/classifier/semantic-bugs/1926759 index 753b9e4d..0e7ca213 100644 --- a/results/classifier/semantic-bugs/1926759 +++ b/results/classifier/semantic-bugs/1926759 @@ -1,15 +1,4 @@ -instruction: 0.938 -semantic: 0.770 -graphic: 0.694 -other: 0.656 -device: 0.644 -vnc: 0.552 -assembly: 0.506 -socket: 0.491 -network: 0.398 -boot: 0.365 -mistranslation: 0.349 -KVM: 0.297 + WFI instruction results in unhandled CPU exception @@ -28,46 +17,4 @@ qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7f5c21d0fa12 WFI aims to enter a low-power state and wait for interrupt. The raised exception seems not a right behavior. I can provide a testcase if you needed. Many thanks. Regards -Muhui - -Please provide a test case binary and your QEMU command line. - - -Oh, and the QEMU version you're using as well, please. - - -cmd： ~/qemu-5.1.0/arm-linux-user/qemu-arm ~/test2 - -QEMU version: qemu-arm version 5.1.0 - -Sorry that I didn't test it on the latest version of QEMU. - -Crash repros on current QEMU. - -This is a bug, in that we shouldn't crash like this. However, it doesn't really make any sense for a userspace program (which is what a binary run by qemu-arm is) to execute the WFI instruction, which is largely intended for OSes to use. If your guest binary needs to use WFI, you should probably be running it on the system emulation QEMU, which does handle WFI correctly. - - -The aarch64 kernel traps and handles WFI as a NOP: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c219bc4e9205 -- so that's probably the most sensible implementation for our linux-user mode. (The aarch32 kernel doesn't trap it, yet, but -"WFI is a NOP" is a valid architectural implementation anyway.) - - -I agree with this implementation. Though WFI seems make no sense for a userspace program, we should not have assumption that the userspace program will not use this instruction. - -It seems ARM manual does not defined the implementation of function EnterLowPowerState(); However, before executing this instruction, there are some checks like below: - -if PSTATE.EL == EL0 then - // Check for traps described by the OS which may be EL1 or EL2. - AArch32.CheckForWFxTrap(EL1, FALSE); - -I am not sure whether it is complex/required to implement this in QEMU. Maybe patch the WFI as a NOP looks like the best idea at this moment. - -We do implement those traps, but only in the system mode emulator, because it makes no sense to trap to EL2 in the usermode emulator where EL2 doesn't exist. - - -Should be fixed by: -https://<email address hidden>/ - - -Fix has been merged: -https://gitlab.com/qemu-project/qemu/-/commit/5b2c8af89b82a671137a - +Muhui \ No newline at end of file |