From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLumM-0008IM-1y for qemu-devel@nongnu.org; Wed, 20 Jan 2016 10:34:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLumG-0003hQ-Dp for qemu-devel@nongnu.org; Wed, 20 Jan 2016 10:34:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36550) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLumG-0003h8-8t for qemu-devel@nongnu.org; Wed, 20 Jan 2016 10:34:32 -0500 Date: Wed, 20 Jan 2016 13:34:29 -0200 From: Eduardo Habkost Message-ID: <20160120153429.GA4218@thinpad.lan.raisama.net> References: <1452257883-19549-1-git-send-email-kraxel@redhat.com> <20160119123739.GA27855@thinpad.lan.raisama.net> <1453301733.11804.142.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1453301733.11804.142.camel@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2] pc: allow raising low memory via max-ram-below-4g option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Paolo Bonzini , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Richard Henderson On Wed, Jan 20, 2016 at 03:55:33PM +0100, Gerd Hoffmann wrote: > Hi, > > > > + * qemu -M pc,max-ram-below-4g=2G -m 4G -> 2048M low, 2048M high > > > I assume max-ram-below-4g > 3.5G was unsupported before, and we > > are breaking compatibility intentionally. > > max-ram-below-4g did only reduce memory, so max-ram-below-4g > 3.5G (or > max-ram-below-4g > 3G with gigabyte align) had no effect and therefore > is something pretty pointless. I see. So, if max-ram-below-4g > 3G with gigabyte align was unsupported too, my example below is also not relevant regarding compatibility. > > I'd expect the one case quoted above to be the only case relevant in > practice (i.e. move split from 3G to 2G for more PCI I/O space), > especially given that the option was added after gigabyte alignment > support. > > > Because this patch also > > changes the resulting memory layout when > > 3G < max_ram_below_4g < ram_size < 3.5G > > e.g.: > > qemu -M pc,max-ram-below-4g=3200M -m 3328M > > Ah, I see. With the patch applied the gigabyte align option is weighed > higher, so qemu wouldn't give you 3200M lowmem. I would be highly > surprised to see such a configuration in the wild ... The new behavior looks OK, considering that the option is just "_max_ RAM below 4G", not "split lowmem at this exact address". But it is inconsistent with the behavior when max-ram-below-4g < 3G (where gigabyte_align is ignored), and something we will need to keep compatibility for a long time. Considering that we never supported gigabyte_align && max_ram_below_4g > 3G || max_ram_below_4g > 3.5G before, we could simply remove the MachineClass::gigabyte_align field from pc_piix, and just do the following: * pc > 1.7: max_ram_below_4g = 3G (equivalent to gigabyte_align=true) * pc <= 1.7: max_ram_below_4g = 3.5G (equivalent to gigabyte_align=false) -- Eduardo