From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: hypercall execution path? Date: Thu, 22 Feb 2007 20:46:54 +0000 Message-ID: <1172177214.19233.32.camel@localhost.localdomain> References: <45DDD02E.40007@thepaynes.cc> <1172168208.12407.26.camel@lapbode42.lrr.in.tum.de> <1172168289.12407.28.camel@lapbode42.lrr.in.tum.de> <45DDE128.1040106@thepaynes.cc> <1172169424.20968.54.camel@localhost.localdomain> <45DDEAD5.1010703@thepaynes.cc> <1172174731.19233.6.camel@localhost.localdomain> <45DDFCEE.6020201@thepaynes.cc> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45DDFCEE.6020201@thepaynes.cc> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Bryan D. Payne" Cc: Xen Developers List-Id: xen-devel@lists.xenproject.org On Thu, 2007-02-22 at 15:28 -0500, Bryan D. Payne wrote: > uint32_t eip = sd->vcpu[0]->arch.guest_context.user_regs.eip; > gdprintk(XENLOG_WARNING, "eip=0x%x", eip); sd is current->domain here so the guest context is saved on the stack rather than in the domain structure. Therefore you need to use guest_cpu_user_regs()->eip instead. I should have thought of that before, sorry. The context in the vcpu's arch.guest_context will be a stale left over from the last time the domain was rescheduled, which is why it is doing a sched_op since it was presumably just waking up from idle. Ian.