Revision a053477b7c6e5094247986de3aa2f0aa139cbb42 authored by Victor Kamensky on 23 March 2018, 18:26:45 UTC, committed by Michael Roth on 21 June 2018, 01:45:00 UTC
In OE project 4.15 linux kernel boot hang was observed under single cpu aarch64 qemu. Kernel code was in a loop waiting for vtimer arrival, spinning in TC generated blocks, while interrupt was pending unprocessed. This happened because when qemu tried to handle vtimer interrupt target had interrupts disabled, as result flag indicating TCG exit, cpu->icount_decr.u16.high, was cleared but arm_cpu_exec_interrupt function did not call arm_cpu_do_interrupt to process interrupt. Later when target reenabled interrupts, it happened without exit into main loop, so following code that waited for result of interrupt execution run in infinite loop. To solve the problem instructions that operate on CPU sys state (i.e enable/disable interrupt), and marked as DISAS_UPDATE, should be considered as DISAS_EXIT variant, and should be forced to exit back to main loop so qemu will have a chance processing pending CPU state updates, including pending interrupts. This change brings consistency with how DISAS_UPDATE is treated in aarch32 case. CC: Peter Maydell <peter.maydell@linaro.org> CC: Alex Bennée <alex.bennee@linaro.org> CC: qemu-stable@nongnu.org Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Victor Kamensky <kamensky@cisco.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 1521526368-1996-1-git-send-email-kamensky@cisco.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit a75a52d62418dafe462be4fe30485501d1010bb9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
1 parent 7c22c5a
trace-events
# scsi/pr-manager.c
pr_manager_execute(int fd, int cmd, int sa, void *opaque) "fd=%d cmd=0x%02x service action=0x%02x opaque=%p"
pr_manager_run(int fd, int cmd, int sa) "fd=%d cmd=0x%02x service action=0x%02x"
Computing file changes ...