[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.