From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkA5x-00012k-89 for qemu-devel@nongnu.org; Mon, 30 Jul 2018 11:28:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fkA5u-0001HW-Hp for qemu-devel@nongnu.org; Mon, 30 Jul 2018 11:28:25 -0400 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> From: David Hildenbrand Message-ID: <534864ae-172c-ff27-0584-4e69da18742f@redhat.com> Date: Mon, 30 Jul 2018 17:28:19 +0200 MIME-Version: 1.0 In-Reply-To: <95e3d12c-12fb-c983-c0aa-e99c08321a98@de.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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 , Cornelia Huck Cc: Janosch Frank , Thomas Huth , qemu-devel , Alexander Graf , qemu-s390x , Halil Pasic , imbrenda@linux.vnet.ibm.com, Richard Henderson On 30.07.2018 17:20, 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. > > Can we agree on this fix and do the remaining thing later? > Yes. The clean fix should then really only consider mapped memory regions (so the sending side should somehow iterate over them and also only access that memory). Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb