From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkA9w-0004NS-RA for qemu-devel@nongnu.org; Mon, 30 Jul 2018 11:32:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fkA9u-0002lC-2N for qemu-devel@nongnu.org; Mon, 30 Jul 2018 11:32:32 -0400 Date: Mon, 30 Jul 2018 17:32:22 +0200 From: Cornelia Huck Message-ID: <20180730173222.4277f679.cohuck@redhat.com> In-Reply-To: <95e3d12c-12fb-c983-c0aa-e99c08321a98@de.ibm.com> References: <1532959766-53343-1-git-send-email-borntraeger@de.ibm.com> <1bf75ad8-dc90-b94e-0ead-53fdbc72dd4f@redhat.com> <9bdf3ea6-d0f4-d637-3e34-eb43a9821434@redhat.com> <95e3d12c-12fb-c983-c0aa-e99c08321a98@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH 1/1] s390x/sclp: fix maxram calculation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger Cc: David Hildenbrand , Janosch Frank , Thomas Huth , qemu-devel , Alexander Graf , qemu-s390x , Halil Pasic , imbrenda@linux.vnet.ibm.com, Richard Henderson On Mon, 30 Jul 2018 17:20:25 +0200 Christian Borntraeger wrote: > On 07/30/2018 05:17 PM, David Hildenbrand wrote: > > On 30.07.2018 17:00, Christian Borntraeger wrote: > >> > >> > >> On 07/30/2018 04:34 PM, 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. > >>> > >>> So the only problem is that the buffer size between source and target > >>> differ? > >> > >> The problem is that the target tries to access a non-existing buffer when > >> committing all cmma value, so the kernel returns with EFAULT. > >>> > > > > Am I wrong or does CMMA migration code really not care about which parts > > of maxram are actually used (== which memory regions are actually defined)? > > > > If so, this looks broken to me and the right fix is to use ramsize for > > now, because it simply does not support maxram. > > > > (I assume using some -m X,maxmem=X+Y would make it fail in the same way) > > > > (this patch still makes sense and should be done) > > I am looking for the minimal fix for 2.13 and ideally even for 2.12.1. 2.13 is not the QEMU version you are looking for :) > Can we agree on this fix and do the remaining thing later? If you guys agree, I'm happy to queue it to s390-fixes for 3.0-rc3. Just be quick, as I'd need to send it tomorrow morning the latest :) (FWIW, patch looks sane and small enough to me.)