From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1ypk-0006Ow-99 for qemu-devel@nongnu.org; Mon, 08 Jun 2015 11:19:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z1ypd-000584-VE for qemu-devel@nongnu.org; Mon, 08 Jun 2015 11:19:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1ypd-00057Q-Pg for qemu-devel@nongnu.org; Mon, 08 Jun 2015 11:19:21 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 7F43C8E502 for ; Mon, 8 Jun 2015 15:19:21 +0000 (UTC) From: Igor Mammedov Date: Mon, 8 Jun 2015 17:19:11 +0200 Message-Id: <1433776757-61958-1-git-send-email-imammedo@redhat.com> Subject: [Qemu-devel] [RFC v2 0/6] Fix QEMU crash during memory hotplug with vhost=on List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: pbonzini@redhat.com, mst@redhat.com Changelog: v1->v2: * take into account Paolo's review comments * do not overload ram_addr * ifdef linux specific code * reseve HVA using API from exec.c instead of calling mmap() dircely from memory.c * support unmapping of HVA remapped region Series still is RFC due to VHOST issues with small memory amount (i.e. last patch 6/6 isn't usable yet), so I'm posting series mainly for revewing memory API bits. -- When more than ~50 pc-dimm devices are hotplugged with vhost enabled, QEMU will assert in vhost vhost_commit() due to backend refusing to accept too many memory ranges. Series introduces Reserved HVA MemoryRegion container where all hotplugged memory is remapped and passes the single container range to vhost instead of multiple memory ranges for each hotlugged pc-dimm device. It's alternative approach to increasing backend supported memory regions limit since what I've come up with backend side approach is quite a bit more code so far. With this approach it would be possible to extend it to initial memory later and provide a single range for all RAM to vhost, which should speed up its hot-path by replacing current GPA<->HVA lookup loop with offset calculation. Igor Mammedov (6): memory: get rid of memory_region_destructor_ram_from_ptr() memory: introduce MemoryRegion container with reserved HVA range memory: support unmapping of MemoryRegion mapped into HVA parent hostmem: return recreated MemoryRegion if current can't be reused pc: reserve hotpluggable memory range with memory_region_init_hva_range() pc: fix QEMU crashing when more than ~50 memory hotplugged backends/hostmem.c | 6 ++++ exec.c | 67 +++++++++++++++++++++++++++++------------- hw/i386/pc.c | 4 +-- hw/virtio/vhost.c | 15 ++++++++-- include/exec/cpu-common.h | 3 ++ include/exec/memory.h | 57 +++++++++++++++++++++++++++++++++-- include/exec/ram_addr.h | 1 - memory.c | 75 +++++++++++++++++++++++++++++++++++++++++++---- 8 files changed, 194 insertions(+), 34 deletions(-) -- 1.8.3.1