|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Different esps
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
|
|
|
|
|