From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1No1aj-00020g-Ph for qemu-devel@nongnu.org; Sat, 06 Mar 2010 16:31:21 -0500 Received: from [199.232.76.173] (port=41008 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1No1aj-00020P-FB for qemu-devel@nongnu.org; Sat, 06 Mar 2010 16:31:21 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1No1ah-0006bh-Jc for qemu-devel@nongnu.org; Sat, 06 Mar 2010 16:31:21 -0500 Received: from hall.aurel32.net ([88.191.82.174]:60866) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1No1ah-0006bT-8t for qemu-devel@nongnu.org; Sat, 06 Mar 2010 16:31:19 -0500 Date: Sat, 6 Mar 2010 22:31:07 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm Message-ID: <20100306213107.GI14275@volta.aurel32.net> References: <20100223151314.GN17350@us.ibm.com> <4B840A17.9050809@aurel32.net> <20100304212724.GH5860@hall.aurel32.net> <20100304213434.GA17350@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100304213434.GA17350@us.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ryan Harper Cc: Anthony Liguori , qemu-devel@nongnu.org, kvm@vger.kernel.org On Thu, Mar 04, 2010 at 03:34:34PM -0600, Ryan Harper wrote: > * Aurelien Jarno [2010-03-04 15:27]: > > On Tue, Feb 23, 2010 at 06:02:15PM +0100, Aurelien Jarno wrote: > > > Ryan Harper a écrit : > > > > Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. > > > > This patch adds a simple check and error message (much like the 2047 limit on > > > > 32-bit hosts) on ram_size in the control path after we determine we're > > > > not using kvm > > > > > > > > Upstream qemu-kvm is affected if using the -no-kvm option; this patch address > > > > the segfault there as well. > > > > > > It looks like workarounding the real bug. At some point both > > > i386-softmmu (via PAE) and x86_64-softmmu were able to support > 4GB of > > > memory. I remember adding the support long time ago, and testing it with > > > 32GB of emulated RAM. > > > > I have looked into that, and actually one patch to get full support for > > > 4GB of memory was not merged: > > Thanks for looking into this. > > > > > diff --git a/exec.c b/exec.c > > index 8389c54..b0bb058 100644 > > --- a/exec.c > > +++ b/exec.c > > @@ -166,7 +166,7 @@ typedef struct PhysPageDesc { > > */ > > #define L1_BITS (TARGET_VIRT_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS) > > #else > > -#define L1_BITS (32 - L2_BITS - TARGET_PAGE_BITS) > > +#define L1_BITS (TARGET_PHYS_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS) > > #endif > > > > #define L1_SIZE (1 << L1_BITS) > > > > While this patch is acceptable for qemu i386, it creates a big L1 table > > for x86_64 or other 64-bit architectures, resulting in huge memory > > overhead. > > > > The recent multilevel tables patches from Richard Henderson should fix > > the problem for HEAD (I haven't found time to look at them in details). > > > > As this is not something we really want to backport, your patch makes > > sense in stable-0.12. > > Anthony, do you want me to resend and rebase against 0.12-stable? > The patch applies correctly on stable-0.12. I have just applied it. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net