| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] do_iret bug in xen
current is extracted from per processor stack area. so are the registers. right? do_iret gets current and regs from the processor's stack area. so does ret_from_intr. so they both point to a fixed per processor stack area. there are not _different_ stack frames.
On Nov 27, 2007 7:51 PM, Daniel Stodden <
stodden@xxxxxxxxxx> wrote:
On Tue, 2007-11-27 at 18:30 -0500, Ashish Bijlani wrote:
> yeah but the do_iret function is done on behalf of a guest, therefore
> do_iret function forces user cs and user ss
>
> code excerpt
> "
> regs->rip = iret_saved.rip;
> regs->cs = iret_saved.cs | 3; /* force guest privilege */
> regs->rflags = (iret_saved.rflags & ~(EF_IOPL|EF_VM)) | EF_IE;
> regs->rsp = iret_saved.rsp;
> regs->ss = iret_saved.ss | 3; /* force guest privilege */
> "
> this can cause ret_from_intr go to test_all_events and finally go to
> __enter_scheduler
that's the guest context saved in _memory_ (xen stack) which gets
modified -- user or kernel. that's where what it ultimately returns _to_
upon return _from_ do_iret. with an interrupted do_iret, the switch in
ret_from_intr would be yet another stack frame above, and that would be
xen being interrupted.
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@xxxxxxxxxxPGP 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