Re: [RFC] event channels and xen callbacks

[Mathieu Ropert <mro@adviseo.fr>]

Keir Fraser wrote:

>
> On 4 Apr 2006, at 17:10, Mathieu Ropert wrote:
>
>> i'm currently playing a bit with event channels and hypervisor 
>> callbacks, and i find myself stuck because i miss some informations. 
>> Maybe you can give me some hints:
>>
>> on amd64 arch, i'd like to know about hypervisor callback: ie, stack 
>> layout when
>> called by Xen, stack location in memory (is it using the TSS entry as 
>> hardware  traps do?) and finally, about how HYPERVISOR_iret() expects 
>> to find the stack upon call (like when you used iret? or something 
>> else?).
>>
>> I may write a little paper or tutorial from i've learned and didn't 
>> found in Xen doc after i get a better view of the whole thing...
>
>
> 1. The stack layout on callback is just as for a native hardware 
> interrupt or exception. Those exceptions that push an error code when 
> running natively also do so when running on Xen, for example.
>
> 2. The TSS isn't fully virtualised by Xen -- instead you register your 
> kernel stack with the stack_switch() hypercall. Calling this is 
> equivalent to writing your stack pointer into your TSS when running 
> natively.
>
> 3. When calling HYPERVISOR_iret() there should be a iret_context 
> swtructure at the top of the stack. See its definition, and a big 
> comment, in xen/include/public/arch-x86_64.h.
>
>  -- Keir
>
Hi,

all those helped me alot, but i'm now getting some trouble with my 
callback handler. I can't figure out why, but Xen call it with some odd 
rsp (about 5 pages below the rsp i have when the callback occur). I'm 
still in kernel mode when the callback happen (from what i saw, when 
processing events before returning to guest after an hypercall) so my 
stack isn't supposed to be changed from what i heard.
Oddly, this isn't happening with my trap handlers (i tried to trigger 
some faults and dump the stack, all is fine) which are supposed to have 
the same behavior.
The only difference i see is that bounce frame is created in Xen by the 
syscall handler and not by the trap handler, but shouldn't be any 
different, should it?
Have anyone ever got this issue, maybe i forgot to setup something prior 
to enabling events...

Thanks!
Mathieu