From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr8TF-0004CR-VA for qemu-devel@nongnu.org; Wed, 19 Nov 2014 11:51:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr8T9-0002RP-Lt for qemu-devel@nongnu.org; Wed, 19 Nov 2014 11:51:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr8T9-0002PT-E6 for qemu-devel@nongnu.org; Wed, 19 Nov 2014 11:51:03 -0500 From: Juan Quintela In-Reply-To: <546CA6F4.9050102@redhat.com> (Paolo Bonzini's message of "Wed, 19 Nov 2014 15:19:32 +0100") References: <1416254843-16859-1-git-send-email-mst@redhat.com> <1416254843-16859-3-git-send-email-mst@redhat.com> <87a93nmggx.fsf@elfo.elfo> <546CA6F4.9050102@redhat.com> Date: Wed, 19 Nov 2014 17:50:55 +0100 Message-ID: <878uj7kuc0.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , QEMU Developers , "Dr. David Alan Gilbert" , "Michael S. Tsirkin" Paolo Bonzini wrote: > On 19/11/2014 15:10, Peter Maydell wrote: > It does already, for example PPC uses it for its IOMMU tables. > > But in any case this is really just memory that is auto-resized on > migration. And it can work even if it is mapped in memory, as long as > your resize callback (or some post_load code executed while migrating > devices) does something useful to update the memory map. Let's call it > like what it is. > > Basically it is an "I know how to deal with the source's configuration > whatever it is, so I'm not bothering to reconstruct it equivalently on > the destination" flag. > > The fine print is that it will create more differences between a given > machine type on different versions of QEMU. It can have ripple effects > on the memory map and it can make existing VMs a bit more likely to > break when updating QEMU. This is why I do not particularly like it, > and I posted different patches to do the same thing. I understand that > it is a simple fix that will mostly work and probably avoids work more > than causing it. > > And BTW, those patches are still unreviewed,. Juan, "do as you > preach"---review patches that are closer to what you preach. And > Michael, you too---review patches in addition to asking people to review > yours, so that we can compare the approaches. I will review them, for the migration bits. But my ACPI knowledge is basically: when I see ACPI, I run in the other direction O:-) (*) Later, Juan. (*) I think that this is all that is needed to know about ACPI O:-)