blob: fc3f5ea77b0963ab32acc701dc8bc839473d9c10 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
BSD bootloader halts with hypervisor.framework
Guest: FreeBSD 12.0 Install CD
Host: MacOS 11.14.3 qemu master at 90fb864a7df0a9af677352e94f8225f7b03de922
Command arguments:
qemu-system-x86_64 -m 4000m -cdrom Downloads/FreeBSD-12.0-RELEASE-amd64-bootonly.iso
When qemu was run with -accel hvf, the bootloader would halt after showing the menu. The bootloader would not respond to any keyboard events.
Without acceleration option, the bootloader would count down to zero and proceed.
Git bisect shows that 92d5f1a4147c3722b5e9a8bcfb7dc261b7a8b855 is the first bad commit.
Author: Paolo Bonzini <email address hidden>
Date: Tue Aug 21 15:31:24 2018 +0200
target/i386: unify masking of interrupts
Interrupt handling depends on various flags in env->hflags or env->hflags2,
and the exact detail were not exactly replicated between x86_cpu_has_work
and x86_cpu_exec_interrupt. Create a new function that extracts the
highest-priority non-masked interrupt, and use it in both functions.
In good versions (27e18b8952f8b7a1e26350846f8a0d5a9b33bfb8), calls to x86_cpu_has_work(), likely due to IRQ 0, returned interchanging true or false.
In bad versions (92d5f1a4147c3722b5e9a8bcfb7dc261b7a8b855), all calls returned false.
Hi Chen,
Do you see the issue on the latest version of QEMU (v5.0 or master)?
The fix addressed incorrect IRQ inhibition:
https://git.qemu.org/?p=qemu.git;a=commit;h=ddd31732a7379e056749836ff37ff57718083ddb
Thanks,
Roman
Yes, I've verified. It boots after countdown and responds to keyboard events.
|