blob: ac249fd3789bfca14793f98ef64bbc05374eeecf (
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
42
43
44
45
46
47
48
49
50
51
52
53
|
semantic: 0.159
graphic: 0.149
other: 0.104
device: 0.098
performance: 0.088
network: 0.066
PID: 0.064
socket: 0.055
files: 0.048
vnc: 0.043
debug: 0.040
permissions: 0.037
boot: 0.027
KVM: 0.023
performance: 0.275
debug: 0.184
files: 0.144
device: 0.138
other: 0.060
boot: 0.034
KVM: 0.034
semantic: 0.029
PID: 0.027
socket: 0.025
graphic: 0.014
network: 0.014
vnc: 0.012
permissions: 0.011
HPET supports only one IRQ
The emulated HPET only supports triggering IRQ 2. Since MSIs are by default disabled, this severely limits the usefulness of the HPET as only one timer block can effectively be used (otherwise they would share IRQ 2). Ideally, the HPET should support as much timer blocks as CPUs and each timer block can be driven by a different IRQ.
TIMER: HPET at fed00000 -> 0xbf500000.
TIMER: HPET vendor 8086 revision 01: LEGACY 64BIT
TIMER: HPET: cap 8086a201 config 0 period 10000000
TIMER: HPET Timer[0]: config 30 int 4
TIMER: HPET Timer[1]: config 30 int 4
TIMER: HPET Timer[2]: config 30 int 4
The offending code seems to be:
/* advertise availability of ioapic inti2 */
timer->config |= 0x00000004ULL << 32;
in hw/hpet.c hpet_reset().
I assume this has been fixed by this commit here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7a10ef51c2397ac4323b
Or is there still something left to do here?
No. Looks good to me.
|