From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kb6wj-0000JW-1n for qemu-devel@nongnu.org; Thu, 04 Sep 2008 00:59:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kb6wg-0000ID-PZ for qemu-devel@nongnu.org; Thu, 04 Sep 2008 00:59:51 -0400 Received: from [199.232.76.173] (port=54398 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kb6wg-0000IA-LA for qemu-devel@nongnu.org; Thu, 04 Sep 2008 00:59:50 -0400 Received: from wf-out-1314.google.com ([209.85.200.168]:43879) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kb6wg-0000F3-Io for qemu-devel@nongnu.org; Thu, 04 Sep 2008 00:59:50 -0400 Received: by wf-out-1314.google.com with SMTP id 27so3105113wfd.4 for ; Wed, 03 Sep 2008 21:59:48 -0700 (PDT) Message-ID: Date: Thu, 4 Sep 2008 07:59:47 +0300 From: "Kirill A. Shutemov" Subject: Re: [Qemu-devel] linux-user 32/64 bit mremap() problem In-Reply-To: <20080903165652.P92245@stanley.csl.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_28467_27298696.1220504387946" References: <20080903165652.P92245@stanley.csl.cornell.edu> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org ------=_Part_28467_27298696.1220504387946 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, Sep 4, 2008 at 12:01 AM, Vince Weaver wrote: > Hello > > This has been discuessed a year ago > > http://www.nabble.com/linux-user-mmap()-for-32-bit-guest-on-64-bit-host-td12934745.html > http://osdir.com/ml/linux.ports.x86-64.general/2007-10/msg00007.html > but hasn't really been resolved. > > The linux-user mremap() syscall implementation will return a 64-bit value > when running on a 64-bit machine, even when the architecture being simulated > is only 32-bits. > > Has any progress been made on this issue? I might try implementing the > workaround the kernel people suggested. > > This actually prevents one of the perlbmk spec2k benchmarks from running > with sparc32plus emulation on an x86_64 machine. > I have posted patch to the maillist witch add flag MAP_32BIT to mmap and mremap calls. It helps on x86_64 host, but other 64-bit host doesn't support this flag currently. ------=_Part_28467_27298696.1220504387946 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On Thu, Sep 4, 2008 at 12:01 AM, Vince Weaver <vince@csl.cornell.edu> wrote:
Hello

This has been discuessed a year ago
 http://www.nabble.com/linux-user-mmap()-for-32-bit-guest-on-64-bit-host-td12934745.html
 http://osdir.com/ml/linux.ports.x86-64.general/2007-10/msg00007.html
but hasn't really been resolved.

The linux-user mremap() syscall implementation will return a 64-bit value when running on a 64-bit machine, even when the architecture being simulated is only 32-bits.

Has any progress been made on this issue?  I might try implementing the workaround the kernel people suggested.

This actually prevents one of the perlbmk spec2k benchmarks from running with sparc32plus emulation on an x86_64 machine.

I have posted patch to the maillist witch add flag MAP_32BIT to mmap and mremap calls. It helps on x86_64 host, but other 64-bit host doesn't support this flag currently.

------=_Part_28467_27298696.1220504387946--