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: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Different esps
From: Jacob Gorm Hansen <jacob@xxxxxxxx>
Date: Tue, 20 Jan 2004 18:22:55 +0100
Cc: Xen list <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 20 Jan 2004 17:23:01 +0000
Envelope-to: Steven.Hand@xxxxxxxxxxxx
In-reply-to: <E1AizMh-0006Dn-00@xxxxxxxxxxxxxxxxxxxx>
References: <E1AizMh-0006Dn-00@xxxxxxxxxxxxxxxxxxxx>
On Tue, 2004-01-20 at 18:08, Steven Hand wrote:

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

I added this because there otherwise Xen will just kill the domain silently, 
unless there is a debugging option I have overlooked.

about line 329 in traps.c:

  fault_in_hypervisor:
+       printk("fault_in_hypervisor 2\n");
+       printk("dom %d : esp1 %08lx, ss %08lx\n",current->domain, 
current->thread.esp1, current->thread.ss1);
+
+       execution_context_t ctxt;
+    memcpy(&ctxt,
+           get_execution_context(), 
+           sizeof(execution_context_t));
+
+       printk("eip %p esp %p eip %p  addr %p flags %x\n", ctxt.eip, ctxt.esp, 
gtb->eip, addr, ctxt.eflags);


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

0xc3a91ff8 appears to be where ctxt.esp is pointing if you push some
values. The dual 0 eips worry me as well, I have not registered any
event-callbacks for the domain, perhaps that is the reason? But should I
not be allowed to run without registering for interrupts in a brand-new
domain? To me this looks like an interrupt-delivery gone bad.

cheers,
Jacob


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