On Tue, 2004-01-20 at 15:42, Jacob Gorm Hansen wrote:

This is my recovery function, which eip points to when the new domain is started:

static void recover(void) { __cli(); HYPERVISOR_stack_switch(__KERNEL_DS, current->thread.esp0); asm volatile("addl $0x0, -4(%%eax)" : :"eax"(current->thread.esp0)); while(1) HYPERVISOR_console_write("alive",5);

...

I touch the ring1 stack to make sure it is writeable (due to my migration hacks it may not always be).

The output on the serial looks like below. The first four lines are printed by my version of Xen as a response to SCHEDOP_exit:

exit dom 41 : esp1 c3a96000, ss 00000821 eip c00b5b6d esp c3a95ed8 eflags 296 Killing domain 41 Releasing task 41 DOM42: alive DOM42: alive DOM42: alive DOM42: alive DOM42: alive DOM42: alive DOM42: alive DOM42: alive DOM42: alive DOM42: alive DOM42: alive DOM42: alive DOM42: alive fault_in_hypervisor 2 dom 42 : esp1 c3a96000, ss 00000821 eip 00000000 esp c3a92004 eip 00000000 pf-addr c3a91ff8 eflags 10286 Killing domain 42 Releasing task 42

As you can see, the crash is not happening in direct response to some action in the domain, but rather as an effect of something happening outside. I was speculating that perhaps I need to re-register for the timer interrupt, or that the __cli() does not prevent Xen from trying to deliver them?

Btw, the value of 'current' checks out, and is equal to the value before migration.

best, Jacob