On Fri, 25 Jun 2004, Keir Fraser wrote:
> If Xen interrupted a ring-1 activation then the hypervisor_callback
> stack frame will be pushed onto the stack that was interrupted.
>
> If Xen interrupted rings 2 or 3 then it uses SS:ESP specified in your
> call to HYPERVISOR_stack_switch when creating the hypervisor_callback
> stack frame.
>
> The code that creates the callback stack frame and jumps to your
> handler is in xen/arch/x86/entry.S
yeah, I know that code.
It's odd, but this all works fine for everything but hypervisor callbacks.
Really odd.
page faults and all that work fine. I'm looking at a stack dump right now,
from the page fault that occurs after the failed hypervisor_callback, and
i can see my wait loop CS:EIP on the stack, and the hypervisor callback
address on the stack, and the page fault frame that xen built, and it has
a bad SS:SP pair.
The sequence is:
Still in kernel, before starting up first user proc, I enable
interrupts (mask = 0) and just start a wait loop, and wait to get
interrupted. I do. I then take a fault, and CS:EIP is my hypervisor
callback function in Plan 9, as observed from page fault stack.
If I do this in hypervisor_callback function:
IRETL
then I never get the bogus page fault.
If I do this:
PUSHL AX
IRETL
Then I get the trap at the CS:EIP of hypervisor callback, and the SS:SP on
the stack is just wrong.
So it's a guest in Ring 1, getting interrupted by Xen, callback function
is activated, but callback function has an unusable ss:sp.
blah. So close.
ron
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home