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] current not very current (vs curr_vcpu)

On Fri, 19 Feb 2010 21:34:39 +0000
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:

> On 19/02/2010 19:23, "Mukesh Rathor" <mukesh.rathor@xxxxxxxxxx> wrote:
> 
> > Yes, but my point is it doesn't appear to be running idle vcpu as
> > indicated by regs->rsp and regs->rip. They both point to dom0
> > context. This from printk in ns16550_interrupt().
> > 
> > To rephrase the question, if regs->rip and regs->rsp show guest
> > context in do_IRQ(), then current must always point to guest vcpu,
> > correct?
> 
> Oh, so the serial interrupt interrupted a guest's execution? Then yes,
> current should point at that guest.
> 
>  -- Keir
> 

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.

It appears to me, that guest_mode() needs to check if current
rsp is already guest_cpu_user_regs() in which case a stack switch
has not happened, and guest_mode should be false. 
Or, perhaps, just not enable interrupts in context_switch and do 
it in idle_loop().

what do you think?

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel