From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDCwl-0003uG-7X for qemu-devel@nongnu.org; Mon, 19 Jan 2015 09:04:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDCwg-0005Uf-9O for qemu-devel@nongnu.org; Mon, 19 Jan 2015 09:04:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDCwg-0005UD-2J for qemu-devel@nongnu.org; Mon, 19 Jan 2015 09:04:46 -0500 Date: Mon, 19 Jan 2015 15:04:38 +0100 From: Igor Mammedov Message-ID: <20150119150438.5d0b0ab9@nial.brq.redhat.com> In-Reply-To: <54ACE133.4080208@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-Transfer-Encoding: 7bit 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 , Juan Quintela , qemu-devel@nongnu.org, dgilbert@redhat.com, "Michael S. Tsirkin" On Wed, 07 Jan 2015 08:33:07 +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. My ACPI patches, mainly do not include any trimming due to the fact that it will break current migration (i.e. blob size conditions will change and break currently working setups). With this series we could trim not present devices descriptions from ACPI tables reducing its size safely (wrt migration). IMHO this series should be in tree before any trimming is implemented and the sooner the better (i.e. we would be able do forward/backward migration to/from 2.3(with theses patches) to/from newer versions with trimmed tables). I'm in favor of this series approach as it let us take care of ACPI tables migration once and don't care about it anymore VS Paolo's byte-by-byte compatible SSDT for each machine type whenever we change/fix ACPI tables. > > Paolo >