[RFC] event channels and xen callbacks

[RFC] event channels and xen callbacks

[Mathieu Ropert]

Hi,

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...

Regards,

Mathieu

Re: [RFC] event channels and xen callbacks

[Keir Fraser]

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

Re: [RFC] event channels and xen callbacks

[Mathieu Ropert]

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
>

Thanks Keir, that helped me a lot!


Regards,

Mathieu

Re: [RFC] event channels and xen callbacks

[Mathieu Ropert]

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