| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] do_iret bug in xen
On Tue, 2007-11-27 at 20:15 -0500, Ashish Bijlani wrote:
> current is extracted from per processor stack area. so are the
> registers. right?
yes.
> do_iret gets current and regs from the processor's stack area. so does
> ret_from_intr.
yes. but the latter from a different stack *frame* in the case you're
concerned about. same stack, though.
> so they both point to a fixed per processor stack area. there are not
> _different_ stack frames.
i see what you mean. let's look at the stack when an IPI occurs to
trigger a context switch.
--snip--
guest calls __HYPERVISOR_iret (saves guest cs)
do_iret tinkers with guest_cpu_user_regs
IPI caught (saves xen cs)
ret_from_intr tests xen (!!) cs, not guest cs
do_iret continues and finishes. same current.
test_all_events calls do_softirq. schedules. new current.
return to new current.
--snap--
UREGS_cs in entry.S refers to the interrupted context, not the saved
guest context. this may be the same: the IPI would have mattered if it
interrupted the guest. it did not. so the softirq will only be run
before returning to the guest, not in between.
regards,
daniel
--
Daniel Stodden
LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München D-85748 Garching
http://www.lrr.in.tum.de/~stodden mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home