From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqSba-0001Ke-EC for qemu-devel@nongnu.org; Mon, 17 Nov 2014 15:09:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqSbT-0005qY-Gf for qemu-devel@nongnu.org; Mon, 17 Nov 2014 15:08:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqSbT-0005qU-98 for qemu-devel@nongnu.org; Mon, 17 Nov 2014 15:08:51 -0500 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 (8.14.4/8.14.4) with ESMTP id sAHK8nbd007064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 17 Nov 2014 15:08:50 -0500 Date: Mon, 17 Nov 2014 22:08:46 +0200 From: "Michael S. Tsirkin" Message-ID: <1416254843-16859-1-git-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] [PATCH 0/5] pc: make ROMs resizeable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: pbonzini@redhat.com, dgilbert@redhat.com, Juan Quintela At the moment we migrate ROMs which reside in fw cfg, which allows changing ROM code at will, and supports migrating largish blocks early, with good performance. However, we are running into a problem: changing size breaks migration every time. This already requires somewhat messy compatibility support in acpi generation code, and it looks like there'll be more to come. Rather than try to guess the correct size once and for all, this patchset tries to make code future-proof, by adding support for resizeable ram blocks. A (possibly very high) amount of space in ram_addr_t space is reserved for each block, but never allocated. If incoming block size differs from current size, block is reallocated. FW CFG is also notified and updated accordingly. To simplify things, I didn't add support for resizing actual RAM: device RAM such as fw cfg ROMs are never mapped into guests directly, so instead I added an API to flag device RAM explicitly, and manage them using simple alloc/free/realloc Considering this promises to rid us of worries about ROM size considerations once and for all, I thinking about pushing this as a "kind of bugfix" before 2.2, so we don't need to maintain more band-aids in 2.3 and on. Note: migration stream is unaffected by these patches. This makes it possible to enable this functionality unconditionally, for all machine types. In the future, this might be handy for other things, such as changing kernels loaded on command line across migrations. Note: cross version migration testing still ongoing, I'll definitely complete that before pushing it out. Michael S. Tsirkin (5): cpu: add cpu_physical_memory_clear_dirty_range_nocode exec: qemu_ram_alloc_device, qemu_ram_resize arch_init: support resizing on incoming migration memory: interface to allocate device ram acpi-build: make ROMs device RAM, make them resizeable hw/lm32/lm32_hwsetup.h | 3 +- include/exec/cpu-all.h | 8 +++- include/exec/memory.h | 22 ++++++++++ include/exec/ram_addr.h | 15 +++++++ include/hw/loader.h | 4 +- arch_init.c | 13 +++--- exec.c | 113 +++++++++++++++++++++++++++++++++++++++++++----- hw/core/loader.c | 18 ++++++-- hw/i386/acpi-build.c | 19 +++++--- memory.c | 17 ++++++++ 10 files changed, 202 insertions(+), 30 deletions(-) -- MST