WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Different esps

To: Jacob Gorm Hansen <jacobg@xxxxxxx>
Subject: Re: [Xen-devel] Different esps
From: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Date: Tue, 20 Jan 2004 17:08:34 +0000
Cc: Steven Hand <Steven.Hand@xxxxxxxxxxxx>, Xen list <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 20 Jan 2004 17:08:35 +0000
Envelope-to: Steven.Hand@xxxxxxxxxxxx
In-reply-to: Your message of "Tue, 20 Jan 2004 16:40:14 +0100." <1074613214.1023.289.camel@jacobg>

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

The __cli() should certainly prevent any events from being delivered. 

It's tricky to work out what the above means as you've clearly hacked 
Xen to e.g print "fault_in_hypervisor 2" (is 2 the error_code? is 
there any reason you've added this stuff in place of the regular code 
in do_trap() or do_page_fault()?). Can you post the code/diffs for 
these parts of xen? 

What is at 0xc3a91ff8? Have you actually taken a page fault? I note 
that zero eips are not so good -- but OTOH I don't know what those
values you print actually are [partic given there are two eips]... 
plus if we're really multiply faulting in the hypervisor, all bets
may well be off... 

cheers, 

S.

<Prev in Thread] Current Thread [Next in Thread>