From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkAOK-0006Ro-RX for qemu-devel@nongnu.org; Mon, 30 Jul 2018 11:47:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fkAOG-0000TJ-MO for qemu-devel@nongnu.org; Mon, 30 Jul 2018 11:47:24 -0400 Date: Mon, 30 Jul 2018 17:47:14 +0200 From: Cornelia Huck Message-ID: <20180730174714.3678f0fa.cohuck@redhat.com> In-Reply-To: <2a2bedc4-e7c6-4284-51d7-94dae1ec6094@redhat.com> References: <1532959766-53343-1-git-send-email-borntraeger@de.ibm.com> <2a2bedc4-e7c6-4284-51d7-94dae1ec6094@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/1] s390x/sclp: fix maxram calculation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand Cc: Christian Borntraeger , qemu-devel , qemu-s390x , Alexander Graf , Thomas Huth , Richard Henderson , Janosch Frank , Halil Pasic , imbrenda@linux.vnet.ibm.com On Mon, 30 Jul 2018 17:43:42 +0200 David Hildenbrand wrote: > On 30.07.2018 16:09, Christian Borntraeger wrote: > > We clamp down ram_size to match the sclp increment size. We do > > not do the same for maxram_size, which means for large guests > > with some sizes (e.g. -m 50000) maxram_size differs from ram_size. > > This can break other code (e.g. CMMA migration) which uses maxram_size > > to calculate the number of pages and then throws some errors. > > > > Fixes: 82fab5c5b90e468f3e9d54c ("s390x/sclp: remove memory hotplug support") > > Signed-off-by: Christian Borntraeger > > CC: qemu-stable@nongnu.org > > CC: David Hildenbrand > > --- > > hw/s390x/sclp.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c > > index bd2a024..4510a80 100644 > > --- a/hw/s390x/sclp.c > > +++ b/hw/s390x/sclp.c > > @@ -320,6 +320,7 @@ static void sclp_memory_init(SCLPDevice *sclp) > > initial_mem = initial_mem >> increment_size << increment_size; > > > > machine->ram_size = initial_mem; > > + machine->maxram_size = initial_mem; > > /* let's propagate the changed ram size into the global variable. */ > > ram_size = initial_mem; > > } > > > > BTW, I handle it in may private patch like this > > static inline SCLPDevice *get_sclp_device(void) > { > @@ -319,9 +321,12 @@ static void sclp_memory_init(SCLPDevice *sclp) > * down to align with the nearest increment boundary. */ > initial_mem = initial_mem >> increment_size << increment_size; > > - machine->ram_size = initial_mem; > - /* let's propagate the changed ram size into the global variable. */ > - ram_size = initial_mem; > + /* propagate the changed ram size into the different places */ > + if (initial_mem != machine->ram_size) { > + machine->maxram_size -= machine->ram_size - initial_mem; > + machine->ram_size = initial_mem; > + ram_size = initial_mem; > + } > } > > You would right now overwrite any maxmem setting (which might be ok as > we don't support it yet). > So, will you (for whatever value of 'you') submit more patches for 3.1?