* [Qemu-devel] [Bug 720657] [NEW] SVM intercept for VINTR exits too early
@ 2011-02-17 11:51 Udo Steinberg
2017-03-15 8:08 ` [Qemu-devel] [Bug 720657] " Thomas Huth
2017-05-15 4:17 ` Launchpad Bug Tracker
0 siblings, 2 replies; 3+ messages in thread
From: Udo Steinberg @ 2011-02-17 11:51 UTC (permalink / raw)
To: qemu-devel
Public bug reported:
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).
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/720657
Title:
SVM intercept for VINTR exits too early
Status in QEMU:
New
Bug description:
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).
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Qemu-devel] [Bug 720657] Re: SVM intercept for VINTR exits too early
2011-02-17 11:51 [Qemu-devel] [Bug 720657] [NEW] SVM intercept for VINTR exits too early Udo Steinberg
@ 2017-03-15 8:08 ` Thomas Huth
2017-05-15 4:17 ` Launchpad Bug Tracker
1 sibling, 0 replies; 3+ messages in thread
From: Thomas Huth @ 2017-03-15 8:08 UTC (permalink / raw)
To: qemu-devel
Triaging old bug tickets ... can you still reproduce this problem with
the latest version of QEMU?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/720657
Title:
SVM intercept for VINTR exits too early
Status in QEMU:
Incomplete
Bug description:
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).
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/720657/+subscriptions
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Qemu-devel] [Bug 720657] Re: SVM intercept for VINTR exits too early
2011-02-17 11:51 [Qemu-devel] [Bug 720657] [NEW] SVM intercept for VINTR exits too early Udo Steinberg
2017-03-15 8:08 ` [Qemu-devel] [Bug 720657] " Thomas Huth
@ 2017-05-15 4:17 ` Launchpad Bug Tracker
1 sibling, 0 replies; 3+ messages in thread
From: Launchpad Bug Tracker @ 2017-05-15 4:17 UTC (permalink / raw)
To: qemu-devel
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/720657
Title:
SVM intercept for VINTR exits too early
Status in QEMU:
Expired
Bug description:
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).
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/720657/+subscriptions
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-05-15 4:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-17 11:51 [Qemu-devel] [Bug 720657] [NEW] SVM intercept for VINTR exits too early Udo Steinberg
2017-03-15 8:08 ` [Qemu-devel] [Bug 720657] " Thomas Huth
2017-05-15 4:17 ` Launchpad Bug Tracker
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.