From: Keir Fraser <keir.fraser@eu.citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: current not very current (vs curr_vcpu)
Date: Sat, 20 Feb 2010 07:45:26 +0000 [thread overview]
Message-ID: <C7A54396.ACF2%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <20100219195003.6d1fb125@mantra.us.oracle.com>
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
next prev parent reply other threads:[~2010-02-20 7:45 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 [this message]
2010-02-22 18:59 ` Mukesh Rathor
2010-02-23 19:46 ` Mukesh Rathor
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=C7A54396.ACF2%keir.fraser@eu.citrix.com \
--to=keir.fraser@eu.citrix.com \
--cc=Xen-devel@lists.xensource.com \
--cc=mukesh.rathor@oracle.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).