From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qgheh-0003Qx-Pj for qemu-devel@nongnu.org; Tue, 12 Jul 2011 14:26:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QghYm-0003kw-2U for qemu-devel@nongnu.org; Tue, 12 Jul 2011 14:19:56 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:38743) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QghYl-0003kq-Tj for qemu-devel@nongnu.org; Tue, 12 Jul 2011 14:19:52 -0400 Received: by gyf2 with SMTP id 2so2440885gyf.4 for ; Tue, 12 Jul 2011 11:19:51 -0700 (PDT) MIME-Version: 1.0 Sender: admin@mercurysquad.com In-Reply-To: <20110712171419.119190@gmx.net> References: <20110712171419.119190@gmx.net> Date: Tue, 12 Jul 2011 23:49:50 +0530 Message-ID: From: Prashant Vaibhav Content-Type: multipart/alternative; boundary=001636ed76437fcb8d04a7e35871 Subject: Re: [Qemu-devel] Loading ELF binaries with very high base addresses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?TWFyYyBMw7ZybmVy?= Cc: qemu-devel@nongnu.org, agraf@suse.de --001636ed76437fcb8d04a7e35871 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Marc and Alex, Yes it was 0x4<<60, missed a zero. I didn't know about the virtual regions, I assumed it was flat 64-bit. For now I am going with Alex's suggestion and forcing the mmap to happen at a lower memory address, starting at mmap_min_addr. The guest_base is then large, causing a wraparound. This way also the region bits won't be disregarded, but will make 8 contiguous regions giving a flat 64-bit space. I don't know which types of programs make use of different regions simultaneously, will probably have t= o think about it later, but for now this is good enough. ~Prashant On Tue, Jul 12, 2011 at 10:44 PM, "Marc L=C3=B6rner" wrote= : > Hello Prashant, > first of all your "0x4<<64" is wrong it's "0x4<<60". > In Volume 2 of the IASDM page 2:46 you see that these three upper bits > correspond to the 8 virtual regions (here: region 2). > So maybe you can just disregard these bits and use the rest as new offset > to an faked guest_base that fits your needs (e.g. somewhere in your > process space)? > > Regards, > Marc > > >Hello, > > > >I am working on target-ia64, but am stuck during ia64 ELF loading. > > > >Referring to function "probe_guest_base()" in linux-user/elfload.c aroun= d > >line 1350, called from around line 1484 -- > > > >When the main binary is being mmap'd, the host address and guest address > >should ideally be the same. If they're not, a linear search is done by > >increasing the host_address by one page and trying the mmap again. The > >(positive) offset is then saved. > > >The problem occurs with ia64 binaries, which typically start at > >0x4000000000000000 (i.e 0x4<<64). At least on my x86_64 host machine, > >mmap'ing at this address fails. The real_address is of the order of > >0x8<<32. Needless to say, increasing host_address and trying again will > >never reach a lower address to map at. Further, I cannot make it relocat= e > >to a lower host address because the offset (guest_base) is an unsigned >= int > and so the relocation can only happen by a positive offset. > > > >Because of this it is not possible to load any ELF binaries which start > >at such high memory addresses. I can tailor an elf binary to start at a > >lower base address, which might work for that specific case, but I >susp= ect > most existing ia64 binaries start at 0x4<<64 by convention. Also, >the > "hiaddr" is read from elf header which again is set to 0x4<<64 + some > >value. > > > >The existing code works fine with x86_64, for example, because the > >binaries are typically starting at 0x40000, which is easily mmap'd at > >first try. > > > >Any ideas on a workaround? > > > >~Prashant > -- > NEU: FreePhone - kostenlos mobil telefonieren! > Jetzt informieren: http://www.gmx.net/de/go/freephone > --001636ed76437fcb8d04a7e35871 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Marc and Alex,

Yes it was 0x4<<60, missed a= zero. I didn't know about the virtual regions, I assumed it was flat 6= 4-bit.

For now I am going with Alex's suggesti= on and forcing the mmap to happen at a lower memory address, starting at mm= ap_min_addr. The guest_base is then large, causing a wraparound.

This way also the region bits won't be disregarded,= but will make 8 contiguous regions giving a flat 64-bit space. I don't= know which types of programs make use of different regions simultaneously,= will probably have to think about it later, but for now this is good enoug= h.

~Prashant



On Tue, Jul 12, 2011 at 10:44 PM, "Marc L=C3=B6rner&q= uot; <loerner@gmx.de= > wrote:
Hello Prashant,
first of all your "0x4<<64" is wrong it's "0x4<= <60".
In Volume 2 of the IASDM page 2:46 you see that these three upper bits
correspond to the 8 virtual regions (here: region 2).
So maybe you can just disregard these bits and use the rest as new offset to an faked guest_base that fits your needs (e.g. somewhere in your
process space)?

Regards,
Marc

>Hello,
>
>I am working on target-ia64, but am stuck during ia64 ELF loading.
>
>Referring to function "probe_guest_base()" in linux-user/elfl= oad.c around >line 1350, called from around line 1484 --
>
>When the main binary is being mmap'd, the host address and guest ad= dress >should ideally be the same. If they're not, a linear search i= s done by >increasing the host_address by one page and trying the mmap a= gain. The
>(positive) offset is then saved.

>The problem occurs with ia64 binaries, which typically start at >0x4= 000000000000000 =C2=A0(i.e 0x4<<64). At least on my x86_64 host machi= ne, >mmap'ing at this address fails. The real_address is of the orde= r of >0x8<<32. Needless to say, increasing host_address and trying= again will >never reach a lower address to map at. Further, I cannot ma= ke it relocate >to a lower host address because the offset (guest_base) = is an unsigned >int and so the relocation can only happen by a positive = offset.
>
>Because of this it is not possible to load any = ELF binaries which start >at such high memory addresses. I can tailor an= elf binary to start at a >lower base address, which might work for that= specific case, but I >suspect most existing ia64 binaries start at 0x4&= lt;<64 by convention. Also, >the "hiaddr" is read from elf = header which again is set to 0x4<<64 + some >value.
>
>The existing code works fine with x86_64, for example, because the >= binaries are typically starting at 0x40000, which is easily mmap'd at &= gt;first try.
>
>Any ideas on a workaround?
>
>~Prashant
--
NEU: FreePhone - kostenlos mobil telefonieren!
Jetzt informieren: http://www.gmx.net/de/go/freephone

--001636ed76437fcb8d04a7e35871--