From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1hV0-0002sx-Nn for qemu-devel@nongnu.org; Thu, 18 Dec 2014 15:16:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1hUu-0002SI-I3 for qemu-devel@nongnu.org; Thu, 18 Dec 2014 15:16:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57537) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1hUu-0002S2-AW for qemu-devel@nongnu.org; Thu, 18 Dec 2014 15:16:32 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBIKGVeD015388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 18 Dec 2014 15:16:31 -0500 Date: Thu, 18 Dec 2014 20:16:26 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20141218201626.GO4744@work-vm> References: <1418746479-21634-1-git-send-email-mst@redhat.com> <20141218184908.GJ4744@work-vm> <20141218194318.GB6680@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141218194318.GB6680@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 0/8] acpi: make ROMs resizeable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Amit Shah , pbonzini@redhat.com, imammedo@redhat.com, qemu-devel@nongnu.org, Juan Quintela * Michael S. Tsirkin (mst@redhat.com) wrote: > On Thu, Dec 18, 2014 at 06:49:09PM +0000, Dr. David Alan Gilbert wrote: > > * Michael S. Tsirkin (mst@redhat.com) wrote: > > I'm generally happy with this set for what you're using it for, > > except that I'd like some big hairy warnings in comments > > near the resize functions to make it clear when it's safe > > to do it. > > Really always: whenever resize callback updates all > guest visible state. The outgoing side worries me due to previous painful encounters with arch_init.c's migration_dirty_pages. It's a counter that knows exactly how many pages it has and it gets incremented/decremented and *must* be right otherwise the migration never ends. It's derived from used_pages in your world, so that would change. That's just the one that comes to mind; A comment saying 'Don't use during an outgoing migration' would cover that - but I'm not that confident there aren't other uses we have to be careful of. > > What I don't really understand is how it would work for anything mapped > > into guest address space, how that mapping would be updated. > > > > Dave > > That would be a job of the resize function: it can update kvm. Yes I guess so, I'm just not sure what the guest is going to think about it. Dave > > > > > > > Michael S. Tsirkin (8): > > > cpu: add cpu_physical_memory_clear_dirty_range_nocode > > > memory: add memory_region_set_size > > > exec: cpu_physical_memory_set/clear_dirty_range > > > exec: split length -> used_length/max_length > > > exec: qemu_ram_alloc_resizeable, qemu_ram_resize > > > arch_init: support resizing on incoming migration > > > memory: API to allocate resizeable RAM MR > > > acpi-build: make ROMs RAM blocks resizeable > > > > > > hw/lm32/lm32_hwsetup.h | 3 +- > > > include/exec/cpu-all.h | 12 +++-- > > > include/exec/memory.h | 34 +++++++++++++ > > > include/exec/ram_addr.h | 22 +++++++-- > > > include/hw/loader.h | 4 +- > > > arch_init.c | 28 ++++++----- > > > exec.c | 129 +++++++++++++++++++++++++++++++++++++----------- > > > hw/core/loader.c | 18 +++++-- > > > hw/i386/acpi-build.c | 19 +++++-- > > > memory.c | 33 +++++++++++++ > > > 10 files changed, 242 insertions(+), 60 deletions(-) > > > > > > -- > > > MST > > > > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK