[Qemu-devel] Loading ELF binaries with very high base addresses

[Qemu-devel] Loading ELF binaries with very high base addresses

[Prashant Vaibhav]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

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 around
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 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<<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

[-- Attachment #2: Type: text/html, Size: 1763 bytes --]

Re: [Qemu-devel] Loading ELF binaries with very high base addresses

[Alexander Graf]

[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]

Hi Prashant,


Am 12.07.2011 um 17:29 schrieb Prashant Vaibhav <qemu@mercurysquad.com>:

> 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 around 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 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.

On x86_64 the high 16 bits of the virtual address space have to be equal - either 0x0000 or 0xffff. So the IA64 addresses can't be reflected in x86_64 virtual address space.

For now, you could try to add an ifdef that wraps around to some other lower address in the loop when the va is higher than x86_64 supports.

> 
> 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<<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?

I guess the long-term solution here really is to use the softmmu for linux-user as well - unless we're running 32-on-64.

For now, just force the mapping to somewhere mappable :)

Alex


[-- Attachment #2: Type: text/html, Size: 3589 bytes --]

Re: [Qemu-devel] Loading ELF binaries with very high base addresses

["Marc Lörner"]

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 around >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 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<<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

Re: [Qemu-devel] Loading ELF binaries with very high base addresses

[Prashant Vaibhav]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

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 to
think about it later, but for now this is good enough.

~Prashant



On Tue, Jul 12, 2011 at 10:44 PM, "Marc Lörner" <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/elfload.c around
> >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 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<<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
>

[-- Attachment #2: Type: text/html, Size: 3544 bytes --]

Re: [Qemu-devel] Loading ELF binaries with very high base addresses

[Richard Henderson]

On 07/12/2011 09:43 AM, Alexander Graf wrote:
> For now, just force the mapping to somewhere mappable :)

Unfortunately, I can tell you that there is no such place.

The text segment is mapped by default at 0x4000000000000000
and the data segment is by default mapped at 0x6000000000000000.

If you set guest_base = 0xc000000000000000, which remaps
the text segment to 0, then the data segment will still be
at 0x2000000000000000, which x86_64 still cannot represent.

If you hack the address mapping routines to simply drop the
high bits, then the text and data segments will map on top
of one another.  You can well imagine how well that will work.

The *only* way to solve this is with softmmu.


r~

Re: [Qemu-devel] Loading ELF binaries with very high base addresses

[Peter Maydell]

On 12 July 2011 17:43, Alexander Graf <agraf@suse.de> wrote:
> I guess the long-term solution here really is to use the softmmu for
> linux-user as well - unless we're running 32-on-64.

Even for 32-on-64 we need to control the guest's address space
properly (so we don't do things like gratuitously failing mmap);
in theory you could do that if you could guarantee to mmap 4GB
contiguous at startup to parcel out to the guest, but it would
be simpler and more consistent to just use softmmu in all cases.

-- PMM

Re: [Qemu-devel] Loading ELF binaries with very high base addresses

[Prashant Vaibhav]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

Yes, exactly what happened when loading a non-trivial binary.  :-(
Oh well.


On Wed, Jul 13, 2011 at 12:04 AM, Richard Henderson <rth@twiddle.net> wrote:

> On 07/12/2011 09:43 AM, Alexander Graf wrote:
> > For now, just force the mapping to somewhere mappable :)
>
> Unfortunately, I can tell you that there is no such place.
>
> The text segment is mapped by default at 0x4000000000000000
> and the data segment is by default mapped at 0x6000000000000000.
>
> If you set guest_base = 0xc000000000000000, which remaps
> the text segment to 0, then the data segment will still be
> at 0x2000000000000000, which x86_64 still cannot represent.
>
> If you hack the address mapping routines to simply drop the
> high bits, then the text and data segments will map on top
> of one another.  You can well imagine how well that will work.
>
> The *only* way to solve this is with softmmu.
>
>
> r~
>

[-- Attachment #2: Type: text/html, Size: 1264 bytes --]

Re: [Qemu-devel] Loading ELF binaries with very high base addresses

[Richard Henderson]

On 07/12/2011 01:58 PM, Prashant Vaibhav wrote:
> Yes, exactly what happened when loading a non-trivial binary.  :-(
> Oh well.

If you've got an ia64 cross-compiler, you could still make
progress on qemu by building your own binaries and linking
them somewhere convenient in the low 64 TB.


r~

Re: [Qemu-devel] Loading ELF binaries with very high base addresses

[Prashant Vaibhav]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

That is what I am doing except that my binaries also don't have any data
section and don't link against any libraries. The text section does start at
0x4000000000000000 but they get mapped at 0x1000 or similar location. I can
also build binaries with low base addresses. When these basic ones are
working I'll move on to figuring out softmmu for more complex (read: real
world) binaries. Thanks for all the suggestions btw, really appreciate it.



On Wed, Jul 13, 2011 at 3:02 AM, Richard Henderson <rth@twiddle.net> wrote:

> On 07/12/2011 01:58 PM, Prashant Vaibhav wrote:
> > Yes, exactly what happened when loading a non-trivial binary.  :-(
> > Oh well.
>
> If you've got an ia64 cross-compiler, you could still make
> progress on qemu by building your own binaries and linking
> them somewhere convenient in the low 64 TB.
>
>
> r~
>

[-- Attachment #2: Type: text/html, Size: 1212 bytes --]