From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8qlx-000250-Pz for qemu-devel@nongnu.org; Wed, 07 Jan 2015 08:35:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y8qlt-0003OU-1D for qemu-devel@nongnu.org; Wed, 07 Jan 2015 08:35:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8qls-0002Ye-L0 for qemu-devel@nongnu.org; Wed, 07 Jan 2015 08:35:36 -0500 Date: Wed, 7 Jan 2015 12:03:13 +0200 From: "Michael S. Tsirkin" Message-ID: <20150107100313.GC24828@redhat.com> References: <1419421800-27505-1-git-send-email-mst@redhat.com> <549AB0AC.8030101@redhat.com> <20141224124138.GA27854@redhat.com> <54ACE133.4080208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54ACE133.4080208@redhat.com> Subject: Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , imammedo@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com, Juan Quintela On Wed, Jan 07, 2015 at 08:33:07AM +0100, Paolo Bonzini wrote: > > > On 24/12/2014 13:41, Michael S. Tsirkin wrote: > >> I don't think these are necessary, and I thought these were just RFC > >> when they were posted. I and mst didn't really understand each other, > >> and I take the fault for not reviewing the submission; however, Peter, > >> please hold these for a little more. > >> > >> Paolo > > > > Yes, please do, I'd like Paolo to review at least the memory core > > changes. > > I don't have any issue with the implementation; I'm just not sure that > this is necessary. > > My point is that until ACPI tables are actually trimmed, migration > really won't be broken. So there is no need to apply these patches > until/unless we are ready to trim the tables. So far, the only case where we *didn't* break migration was when we only did minor changes, in 2.2. So sorry, I don't buy the "reviewed the code and it's safe" argument. There's just too much state. Assume there will be bugs. What is a solution you propose to make at least one way migration work in case of bugs? Without answering this question, I don't see how we can make major changes in the subsystem. I guess this boils down to this: what's the risk associated with merging this patchset? It's a small amount of code. -- MST