From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: hypercall execution path? Date: Thu, 22 Feb 2007 18:37:03 +0000 Message-ID: <1172169424.20968.54.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> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45DDE128.1040106@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 13:30 -0500, Bryan D. Payne wrote: > > so: what does it point at? what's the page address, which offset? > > On my machine (xen 3.0.4_1, linux 2.6.16.33-xen), the EIP register in > the guest's vcpu holds 0xc01013a7. For reference, the hypercall page is > 0xc0101000, this is at offset 0x3a7 on that page. Looking at the > disassembly from that page at this location, I see the following: > > mov 0x1d, %eax > int $0x82 > ret > > The EIP value is pointing at the 'ret' instruction. Looking in the > hypercall table, this (0x1d) is the sched_op hypercall (which is not the > hypercall that I called). > > > > after looking into traps.c: take good care with the layout: hypercall > > pages on x86_32 are 32 (!) bytes per entry (not 8 as the loop body might > > suggest). are your calculations correct? > > I believe so, but you can verify with the information that I provided > above. 0x1d * 32 = 0x3a0... this matches the offset I'm seeing. > > Hopefully someone can help me make sense of this :-) The most common reason for sched_op being called is that the vcpu is idle (SCHEDOP_block). Are you sure you are looking at the correct vcpu? How are you looking at the EIP register? Ian.