From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMBfv-00083L-Qy for qemu-devel@nongnu.org; Thu, 21 Jan 2016 04:37:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMBfs-0004m2-Li for qemu-devel@nongnu.org; Thu, 21 Jan 2016 04:37:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMBfs-0004lu-GT for qemu-devel@nongnu.org; Thu, 21 Jan 2016 04:37:04 -0500 Date: Thu, 21 Jan 2016 11:37:00 +0200 From: "Michael S. Tsirkin" Message-ID: <20160121113307-mutt-send-email-mst@redhat.com> References: <1452257883-19549-1-git-send-email-kraxel@redhat.com> <20160119123739.GA27855@thinpad.lan.raisama.net> <1453301733.11804.142.camel@redhat.com> <20160120153429.GA4218@thinpad.lan.raisama.net> <20160120171504.GB4218@thinpad.lan.raisama.net> <20160120192229-mutt-send-email-mst@redhat.com> <1453362533.11655.26.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1453362533.11655.26.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: Eduardo Habkost , qemu-devel@nongnu.org, Paolo Bonzini , Richard Henderson On Thu, Jan 21, 2016 at 08:48:53AM +0100, Gerd Hoffmann wrote: > On Mi, 2016-01-20 at 19:25 +0200, Michael S. Tsirkin wrote: > > On Wed, Jan 20, 2016 at 03:15:04PM -0200, Eduardo Habkost wrote: > > > On Wed, Jan 20, 2016 at 01:34:29PM -0200, Eduardo Habkost wrote: > > > [...] > > > > 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) > > > > > > Ignore the suggestion above. I forgot that gigabyte_align applies > > > only if ram_size > 3.5GB (so setting max_ram_below_4g = 3G on > > > pc > 1.7 wouldn't work). So, unless somebody has a suggestion > > > that makes this logic simpler: > > > > I wonder whether we should just bite the bullet and ask management to > > maintain the physical memory map for us, instead of trying to give us > > hints. > > I doubt this simplified things, given the backward compatibility > constrains we have. > > cheers, > Gerd That's exactly what would become simple. For backwards compatibility we would leave things alone if the new flags for the memory map aren't specified. This would allow people to e.g. allocate phy address ranges for things like nvdimm which has been problematic in the past. The issue as I see it is not compatibility, but rather creating a way for both management and command line users to figure out valid address ranges. And, it all might just be too complex for users. -- MST