semantic: 0.150
other: 0.145
device: 0.136
PID: 0.090
vnc: 0.083
performance: 0.069
socket: 0.063
graphic: 0.061
debug: 0.058
permissions: 0.042
files: 0.035
network: 0.034
boot: 0.022
KVM: 0.012
debug: 0.702
performance: 0.052
files: 0.046
semantic: 0.040
PID: 0.039
other: 0.038
device: 0.020
boot: 0.012
network: 0.012
socket: 0.009
vnc: 0.009
permissions: 0.008
graphic: 0.007
KVM: 0.005

SVM intercept for VINTR exits too early

The following happens with QEMU-0.14-rc2. QEMU-0.13 did not have this problem.

A guest operating system running inside an SVM VM contains the following code sequence:
c000002b:       fb                      sti    
c000002c:       0f 35                   sysexit 

The following is a list of exits that occur at guest RIP 0xc000002c (other exits omitted for clarity):

exit=0x60 int_shadow=0x1 int_control=0x1000000 inj=0x600000000 rip=0xc000002c
entry: int_shadow=0x1 int_control=0x1000000 inj=0x600000000

(exit due to physical interrupt, correctly reports STI blocking, entry does not inject anything)

exit=0x60 int_shadow=0x1 int_control=0x1000000 inj=0x600000000 rip=0xc000002c
entry: int_shadow=0x1 int_control=0x1100100 inj=0x600000000

(exit due to physical interrupt, correctly reports STI blocking, entry pends a VINTR to cause a VM exit when interrupt window opens. VINTR is being intercepted by the hypervisor.)

exit=0x64 int_shadow=0x0 int_control=0x1100100 inj=0x600000000 rip=0xc000002c
entry: int_shadow=0x0 int_control=0x1000000 inj=0x6800000a0

(exit due to VINTR. At this point STI blocking is still effective - though not reported. Actually, the VINTR exit should occur AFTER the SYSEXIT instruction, not after STI. Due to this bug, the hypervisor injects vector 0xa0 into an interrupt shadow, and things break).

Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU?

[Expired for QEMU because there has been no activity for 60 days.]