On Sat, 20 Feb 2010 07:45:26 +0000
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> On 20/02/2010 03:50, "Mukesh Rathor" <mukesh.rathor@xxxxxxxxxx> wrote:
>
> > ah, I see what's going on. context_switch() is scheduling idle
> > vcpu, and calls continue_idle_domain() to
> > reset_stack_and_jump(idle_loop). well, reset_stack_and_jump() is
> > setting rsp to guest_cpu_user_regs(), and interrupt is coming right
> > at that instant. so:
> >
> > diff = (char *)guest_cpu_user_regs() - (char *)(r) is 0
> >
> > and as a result, guest_mode(regs) == true.
>
> Well, I don't see how this scenario works. If rsp==g_c_u_r() at the
> instant the interrupt comes in, then the stack frame for the
> interrupt will be *above* g_c_u_r(). Thus 'diff' in guest_mode() will
> evaluate non-zero and positive, and regs->{rip,rsp} should point at
> hypervisor code/stack.
>
> Also: in your original email you said regs.rsp pointed at dom0 stack.
> That doesn't tally with you saying that rsp==g_c_u_r() (an address in
> hypervisor space) immediately before the interrupt, in this email.
> Regs->rsp in the scenario you describe here should be exactly equal
> to g_c_u_r().
>
> -- Keir
>
Ok, I think I found it. Initially, my printk in serial_rx() showed
regs == ffff82c48030ff28 == guest_cpu_user_regs
This led me down to reset_stack_and_jump where sp is set to g_c_u_r.
Anyways, on this big box, I'm using virtual serial via the service
processor. So, it looks like serial interrupts are not going thru
do_IRQ(), but ns16550_poll().
__do_softirq -> execute_timer -> ns16550_poll -> serial_rx_interrupt.
However, in ns16550_poll():
struct cpu_user_regs *regs = guest_cpu_user_regs(); <------
The cpu is clearly running idle_vcpu, so current is correctly pointing
to idle vcpu. But guest_mode() is showing guest mode incorrectly.
I'm not much familiar with ns16550 stuff, so cant' think of a fix other
than just setting regs to current stack pointer in ns16550_poll().
__asm__ ( "movq %%rsp,%0" : "=r" (val));
struct cpu_user_regs *regs = val;
Let me know if you like the fix and I'll submit a patch.
thanks,
Mukesh
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home