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

2011-07-12 Thread Marc Lörner
Hello Prashant,
first of all your 0x464 is wrong it's 0x460.
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 
0x4000  (i.e 0x464). At least on my x86_64 host machine, 
mmap'ing at this address fails. The real_address is of the order of 0x832. 
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 0x464 by convention. Also, the hiaddr is 
read from elf header which again is set to 0x464 + some value.

The existing code works fine with x86_64, for example, because the binaries 
are typically starting at 0x4, 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] Patch: cpu-all.h for better cycle counter

2007-03-26 Thread Marc Lörner
On Monday 26 March 2007 22:37, andrzej zaborowski wrote:
 On 26/03/07, Marc Lörner [EMAIL PROTECTED] wrote:
  On Monday 26 March 2007 00:08, andrzej zaborowski wrote:
   On 26/03/07, andrzej zaborowski [EMAIL PROTECTED] wrote:
 
  snip
 
 +# warning non-optimized CPU
 +#include sys/time.h
 +#include time.h
 +
  static inline int64_t cpu_get_real_ticks (void)
  {
 -static int64_t ticks = 0;
 -return ticks++;
 +   struct timeval tv;
 +   static int64_t i = 0;
 +   int64_t j;
 +
 +   gettimeofday(tv, NULL);
 +   do {
 +  j = (tv.tv_sec * (uint64_t) 100) + tv.tv_usec;
 +   } while (i == j);
 +   i = j;
 +   return j;
   
Isn't this an infinite loop? gettimeofday() was left out of the loop.
   
How about return j + (ticks++) instead of the loop? If I understand
correctly it may slow things down to below 1Hz.
  
   (I wanted to say MHz)
 
  I dont think so, in the loop j is set and the while-condition is
  j==i, so unless (tv.tv_sec * (uint64_t) 100) + tv.tv_usec always
  computes the same value the do-while block gets only executed once.

 Well, it does always compute the same value - inside the loop. Doesn't
 it? And across one microsecond also the same value in all calls to
 cpu_get_real_ticks.

 snip

 Regards

okay, sometimes one doesn't see the wood for the trees.
The over and over computation of the same value doesn't make sense, 
so the call of gettimeofday should be in the loop (i think).
-- 
Freundliche Gruesse,
Marc Lörner

Tel.: +49 (0)9103-715-30046
Fax.: +49 (0)9103-715-271
Internet: http://www.hob.de
E-Mail: [EMAIL PROTECTED]

HOB GmbH  Co. KG
Schwadermühlstraße 3
90556 Cadolzburg

Geschaeftsfuehrer Klaus Brandstaetter - Franz Wiedenmann

AG Fuerth  HRA 5180
Steuer-Nr. 218/163/00107
USt-ID-Nr. DE 132747002

Komplementaerin HOB electronic BeteiligungsGmbH
AG Fuerth HRB 3416




Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source

2007-01-16 Thread Marc Lörner
On Tuesday 16 January 2007 15:12, Ottavio Caruso wrote:
 --- Oliver Gerlich [EMAIL PROTECTED] wrote:
  as I was just reading this on german newsticker heise.de:
  http://www.heise.de/open/news/meldung/83680
 
  Also on Slashdot:
  http://it.slashdot.org/it/07/01/15/1631234.shtml
 
  And the original news:
  http://www.virtualbox.org/wiki/News

 Interesting! Does anybody know if and where I could finf a Windows
 binary via http/ftp? Unfortunately I can't torrent!

Hello,
either click at site: http://www.virtualbox.org/wiki/Downloads left on:
VirtualBox 1.3.2 for Windows Hosts, not on the torrent link at the right,
or follow this link to download the msi:
http://www.virtualbox.org/download/1.3.2/VirtualBox_1.3.2_Win_x86.msi


HTH,
Marc


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel