From patchwork Wed Dec 14 01:43:24 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Graf X-Patchwork-Id: 131285 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [140.186.70.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 0AFC51007D3 for ; Wed, 14 Dec 2011 12:43:45 +1100 (EST) Received: from localhost ([::1]:55100 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Radsd-00078s-T9 for incoming@patchwork.ozlabs.org; Tue, 13 Dec 2011 20:43:35 -0500 Received: from eggs.gnu.org ([140.186.70.92]:51932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RadsX-00078n-WD for qemu-devel@nongnu.org; Tue, 13 Dec 2011 20:43:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RadsW-0007lz-MV for qemu-devel@nongnu.org; Tue, 13 Dec 2011 20:43:29 -0500 Received: from cantor2.suse.de ([195.135.220.15]:56461 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RadsW-0007lc-A1 for qemu-devel@nongnu.org; Tue, 13 Dec 2011 20:43:28 -0500 Received: from relay1.suse.de (nat.nue.novell.com [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 0CAF48A95F; Wed, 14 Dec 2011 02:43:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) From: Alexander Graf In-Reply-To: <201112140030.45213.paul@codesourcery.com> Date: Wed, 14 Dec 2011 02:43:24 +0100 Message-Id: <285BCAC5-E270-4B49-9DC5-081A79691BE3@suse.de> References: <1323725761-5629-1-git-send-email-agraf@suse.de> <201112131631.28969.paul@codesourcery.com> <218892C4-3E2C-4278-B0E9-D9FF61E2FCB9@suse.de> <201112140030.45213.paul@codesourcery.com> To: Paul Brook X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-Received-From: 195.135.220.15 Cc: Peter Maydell , Riku Voipio , "dvaleev@suse.com" , "qemu-devel@nongnu.org" , Richard Henderson Subject: Re: [Qemu-devel] [PATCH] PPC: Fix linker scripts on ppc hosts X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On 14.12.2011, at 01:30, Paul Brook wrote: >>>>>>> When compiling qemu statically with multilib on PPC, we hit the >>>>>>> same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49 >>>>>>> is fixing. Do the same here. >>>>>> >>>>>> How many of these ld files can we get rid of if we use -Ttext-segment >>>>>> instead? Generally all we're really caring about is moving the program >>>>>> base around so that it doesn't conflict with the address space we want >>>>>> to use for the client. >>>>> >>>>> Now that we have the automatic GUEST_BASE stuff you shouldn't need to >>>>> do either. >>>> >>>> If it was working, yes :) >>> >>> What doesn't work? I put a fair amout of effort into making it >>> automatically pick a sensible value. If there's some reason that won't >>> work then you probably want to be using -R. >> >> IIRC mmap'ing files would break with 32-on-64, but I'd have to check up on >> the details. I ended up passing MAP_32BIT to all linux-user mmap calla for >> 32-on-x86_64, but that doesn't work with -R. > > Hmm, I thought we'd fixed that. It's the reason h2g_valid exists. > > Either way it should definitely work with -R. I specifically added that to > avoid problems with the host mmap picking inconvenient addresse. > > MAP_32BIT is an unconsionable hack, and doesn't exist on other 64-bit hosts. Yes, I agree. I just sat down once more and checked if I could get it working with -R and everything seems fine so far. Is there any particular reason we're not reserving all of the possible 32 bit address space for 32-on-64 guests? The way it's today with the default being completely broken and -R fixing everything if you give it a large enough value is ... suboptimal. I put this patch onto my tree to make sure we always actually use the -R feature: Alex commit ac233b323ad7e498c665e8c74df7e44de4a542c0 Author: Alexander Graf Date: Wed Dec 14 00:33:28 2011 +0100 linux-user: reserve 4GB of vmem for 32-on-64 When running 32-on-64 bit guests, we should always reserve as much virtual memory as we possibly can for the guest process, so it can never overlap with QEMU address space. Fortunately we already have the infrastructure for that. All that's missing is some sane default value to also make use of it! Signed-off-by: Alexander Graf diff --git a/linux-user/main.c b/linux-user/main.c index 788ff98..3ffee40 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -48,8 +48,19 @@ unsigned long mmap_min_addr; #if defined(CONFIG_USE_GUEST_BASE) unsigned long guest_base; int have_guest_base; +#if (TARGET_LONG_BITS == 32) && (HOST_LONG_BITS == 64) +/* + * When running 32-on-64 we should make sure we can fit all of the possible + * guest address space into a contiguous chunk of virtual host memory. + * + * This way we will never overlap with our own libraries or binaries or stack + * or anything else that QEMU maps. + */ +unsigned long reserved_va = 0xf7000000; +#else unsigned long reserved_va; #endif +#endif static void usage(void); extern int use_stopflag;