From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bryan D. Payne" Subject: Re: hypercall execution path? Date: Thu, 22 Feb 2007 13:30:00 -0500 Message-ID: <45DDE128.1040106@thepaynes.cc> References: <45DDD02E.40007@thepaynes.cc> <1172168208.12407.26.camel@lapbode42.lrr.in.tum.de> <1172168289.12407.28.camel@lapbode42.lrr.in.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1172168289.12407.28.camel@lapbode42.lrr.in.tum.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Daniel Stodden Cc: Xen Developers List-Id: xen-devel@lists.xenproject.org > 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 :-) Thanks, bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org