From nobody Wed Nov 12 10:24:51 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=de.ibm.com ARC-Seal: i=1; a=rsa-sha256; t=1569849749; cv=none; d=zoho.com; s=zohoarc; b=Lh5rkiOWQx95lEHC1kerlyEw9K6x94mpaReCYhKweXZxwSbAtOjH0LzDbNIArsNWqZ0xhquSYdm6SIAtRaPIOgLwZhXA66QMn8ZV4N7TfCoVF0/Tj6Lq+kzTayZyQMy8hVyTxCU3wk2XSi1gf23n5pEQc2ivvg2hTsCBVpxfXvI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1569849749; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=rK0xkjwkBzBlnqMF6d56KozkBd9ektHxGSTdXWVCNlQ=; b=oJSNom3AEFqM23ppq8nZTzeRhTQ+N5fFPPZL/6sA4qu5u5Ndife0sBvI5L+L4QkbLZNB0iyF1DWIEP8pMytrD1NbinJsDWnCCfGp3yR3yi4tuhoBaDw7OKV8U6jox+dRbe7IzV4JyCp85cNGjfdI0xMkXcKUYooVwOgJAGH09VI= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 156984974988752.94144074714302; Mon, 30 Sep 2019 06:22:29 -0700 (PDT) Received: from localhost ([::1]:52336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iEvdE-0006GB-CB for importer@patchew.org; Mon, 30 Sep 2019 09:22:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42323) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iEvbH-0004Ns-LG for qemu-devel@nongnu.org; Mon, 30 Sep 2019 09:20:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iEvbB-00057J-1b for qemu-devel@nongnu.org; Mon, 30 Sep 2019 09:20:24 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:40424 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iEvb6-00051h-SL for qemu-devel@nongnu.org; Mon, 30 Sep 2019 09:20:17 -0400 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x8UDIdY4187491 for ; Mon, 30 Sep 2019 09:20:08 -0400 Received: from e06smtp03.uk.ibm.com (e06smtp03.uk.ibm.com [195.75.94.99]) by mx0b-001b2d01.pphosted.com with ESMTP id 2vbg9w6qbg-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 30 Sep 2019 09:20:08 -0400 Received: from localhost by e06smtp03.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 30 Sep 2019 14:20:05 +0100 Received: from b06avi18626390.portsmouth.uk.ibm.com (9.149.26.192) by e06smtp03.uk.ibm.com (192.168.101.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 30 Sep 2019 14:20:01 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x8UDJV4J38469904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Sep 2019 13:19:31 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5669F52050; Mon, 30 Sep 2019 13:19:59 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTPS id 3C2C65204E; Mon, 30 Sep 2019 13:19:59 +0000 (GMT) Received: by tuxmaker.boeblingen.de.ibm.com (Postfix, from userid 25651) id F1591E020F; Mon, 30 Sep 2019 15:19:58 +0200 (CEST) From: Christian Borntraeger To: Peter Maydell Subject: [PULL 11/12] s390: do not call memory_region_allocate_system_memory() multiple times Date: Mon, 30 Sep 2019 15:19:54 +0200 X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190930131955.101131-1-borntraeger@de.ibm.com> References: <20190930131955.101131-1-borntraeger@de.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 x-cbid: 19093013-0012-0000-0000-00000352126E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19093013-0013-0000-0000-0000218CB4F0 Message-Id: <20190930131955.101131-12-borntraeger@de.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-30_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909300138 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 148.163.158.5 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas Huth , Janosch Frank , Matthew Rosato , David Hildenbrand , Cornelia Huck , qemu-devel , Peter Xu , Halil Pasic , Christian Borntraeger , qemu-s390x , kvm@vger.kernel.org, Igor Mammedov , Paolo Bonzini , Claudio Imbrenda , Collin Walling , Richard Henderson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" From: Igor Mammedov s390 was trying to solve limited KVM memslot size issue by abusing memory_region_allocate_system_memory(), which breaks API contract where the function might be called only once. Beside an invalid use of API, the approach also introduced migration issue, since RAM chunks for each KVM_SLOT_MAX_BYTES are transferred in migration stream as separate RAMBlocks. After discussion [1], it was agreed to break migration from older QEMU for guest with RAM >8Tb (as it was relatively new (since 2.12) and considered to be not actually used downstream). Migration should keep working for guests with less than 8TB and for more than 8TB with QEMU 4.2 and newer binary. In case user tries to migrate more than 8TB guest, between incompatible QEMU versions, migration should fail gracefully due to non-exiting RAMBlock ID or RAMBlock size mismatch. Taking in account above and that now KVM code is able to split too big MemorySection into several memslots, partially revert commit (bb223055b s390-ccw-virtio: allow for systems larger that 7.999TB) and use kvm_set_max_memslot_size() to set KVMSlot size to KVM_SLOT_MAX_BYTES. 1) [PATCH RFC v2 4/4] s390: do not call memory_region_allocate_system_memo= ry() multiple times Signed-off-by: Igor Mammedov Message-Id: <20190924144751.24149-5-imammedo@redhat.com> Acked-by: Peter Xu Signed-off-by: Christian Borntraeger --- hw/s390x/s390-virtio-ccw.c | 30 +++--------------------------- target/s390x/kvm.c | 11 +++++++++++ 2 files changed, 14 insertions(+), 27 deletions(-) diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index 8bfb6684cb72..18ad279a00a3 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -154,39 +154,15 @@ static void virtio_ccw_register_hcalls(void) virtio_ccw_hcall_early_printk); } =20 -/* - * KVM does only support memory slots up to KVM_MEM_MAX_NR_PAGES pages - * as the dirty bitmap must be managed by bitops that take an int as - * position indicator. If we have a guest beyond that we will split off - * new subregions. The split must happen on a segment boundary (1MB). - */ -#define KVM_MEM_MAX_NR_PAGES ((1ULL << 31) - 1) -#define SEG_MSK (~0xfffffULL) -#define KVM_SLOT_MAX_BYTES ((KVM_MEM_MAX_NR_PAGES * TARGET_PAGE_SIZE) & SE= G_MSK) static void s390_memory_init(ram_addr_t mem_size) { MemoryRegion *sysmem =3D get_system_memory(); - ram_addr_t chunk, offset =3D 0; - unsigned int number =3D 0; + MemoryRegion *ram =3D g_new(MemoryRegion, 1); Error *local_err =3D NULL; - gchar *name; =20 /* allocate RAM for core */ - name =3D g_strdup_printf("s390.ram"); - while (mem_size) { - MemoryRegion *ram =3D g_new(MemoryRegion, 1); - uint64_t size =3D mem_size; - - /* KVM does not allow memslots >=3D 8 TB */ - chunk =3D MIN(size, KVM_SLOT_MAX_BYTES); - memory_region_allocate_system_memory(ram, NULL, name, chunk); - memory_region_add_subregion(sysmem, offset, ram); - mem_size -=3D chunk; - offset +=3D chunk; - g_free(name); - name =3D g_strdup_printf("s390.ram.%u", ++number); - } - g_free(name); + memory_region_allocate_system_memory(ram, NULL, "s390.ram", mem_size); + memory_region_add_subregion(sysmem, 0, ram); =20 /* * Configure the maximum page size. As no memory devices were created diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c index 97a662ad0ebf..54864c259c5e 100644 --- a/target/s390x/kvm.c +++ b/target/s390x/kvm.c @@ -28,6 +28,7 @@ #include "cpu.h" #include "internal.h" #include "kvm_s390x.h" +#include "sysemu/kvm_int.h" #include "qapi/error.h" #include "qemu/error-report.h" #include "qemu/timer.h" @@ -122,6 +123,15 @@ */ #define VCPU_IRQ_BUF_SIZE(max_cpus) (sizeof(struct kvm_s390_irq) * \ (max_cpus + NR_LOCAL_IRQS)) +/* + * KVM does only support memory slots up to KVM_MEM_MAX_NR_PAGES pages + * as the dirty bitmap must be managed by bitops that take an int as + * position indicator. If we have a guest beyond that we will split off + * new subregions. The split must happen on a segment boundary (1MB). + */ +#define KVM_MEM_MAX_NR_PAGES ((1ULL << 31) - 1) +#define SEG_MSK (~0xfffffULL) +#define KVM_SLOT_MAX_BYTES ((KVM_MEM_MAX_NR_PAGES * TARGET_PAGE_SIZE) & SE= G_MSK) =20 static CPUWatchpoint hw_watchpoint; /* @@ -355,6 +365,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s) */ /* kvm_vm_enable_cap(s, KVM_CAP_S390_AIS, 0); */ =20 + kvm_set_max_memslot_size(KVM_SLOT_MAX_BYTES); return 0; } =20 --=20 2.21.0