On Tue, 2004-01-20 at 15:42, Jacob Gorm Hansen wrote:
> On Tue, 2004-01-20 at 13:25, Steven Hand wrote:
> > > On Tue, 2004-01-20 at 12:11, Jacob Gorm Hansen wrote:
> >
> > Anyway, can you post -
> >
> > a) what it is you're trying to do in detail (I'm guessing it's
> > to do with migration but not sure what stage you're at) and
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
|
Home