From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: current not very current (vs curr_vcpu)
Date: Tue, 23 Feb 2010 11:46:46 -0800 [thread overview]
Message-ID: <20100223114646.70e196ea@mantra.us.oracle.com> (raw)
In-Reply-To: <C7A54396.ACF2%keir.fraser@eu.citrix.com>
On Sat, 20 Feb 2010 07:45:26 +0000
Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> On 20/02/2010 03:50, "Mukesh Rathor" <mukesh.rathor@oracle.com> 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
next prev parent reply other threads:[~2010-02-23 19:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-19 4:21 current not very current (vs curr_vcpu) Mukesh Rathor
2010-02-19 8:12 ` Keir Fraser
2010-02-19 19:23 ` Mukesh Rathor
2010-02-19 21:34 ` Keir Fraser
2010-02-20 3:50 ` Mukesh Rathor
2010-02-20 7:45 ` Keir Fraser
2010-02-22 18:59 ` Mukesh Rathor
2010-02-23 19:46 ` Mukesh Rathor [this message]
2010-02-23 21:03 ` Keir Fraser
2010-02-24 3:55 ` Mukesh Rathor
2010-02-24 10:45 ` Keir Fraser
2010-02-25 1:06 ` Mukesh Rathor
2010-02-25 8:07 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100223114646.70e196ea@mantra.us.oracle.com \
--to=mukesh.rathor@oracle.com \
--cc=Xen-devel@lists.xensource.com \
--cc=keir.fraser@eu.citrix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).