[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |