From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlhFP-0003IH-5f for qemu-devel@nongnu.org; Tue, 04 Nov 2014 11:46:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlhFJ-0004pb-0I for qemu-devel@nongnu.org; Tue, 04 Nov 2014 11:46:23 -0500 Date: Tue, 4 Nov 2014 18:46:10 +0200 From: "Michael S. Tsirkin" Message-ID: <20141104164610.GA32459@redhat.com> References: <1406303338-13212-1-git-send-email-imammedo@redhat.com> <1406303338-13212-3-git-send-email-imammedo@redhat.com> <20141103173627.GC29967@work-vm> <5458FF16.6050201@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5458FF16.6050201@redhat.com> Subject: Re: [Qemu-devel] [PATCH for-2.1 2/2] acpi: mark ACPI tables ROM blob as extend-able on migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, qemu-stable@nongnu.org, "Dr. David Alan Gilbert" , Igor Mammedov , lersek@redhat.com On Tue, Nov 04, 2014 at 05:30:14PM +0100, Paolo Bonzini wrote: > On 03/11/2014 18:36, Dr. David Alan Gilbert wrote: > > 1) It's a block of data that's never mapped into the guests address > > space > > 2) It can change, but only at guest reset > > 3) Worst case is it can get upto about 2MB in size > > > > it's pretty marginal whether this thing should be a RAMBlock, > > it doesn't feel like normal RAM or ROM in most ways; but there > > again 2MB is getting a bit large for the device state; hmm. > > And also I think changing migration format gratuitously is bad. We > decided to make these RAMs, which has some advantages and turned out to > have some possible disadvantages, but it's not a big deal. They are > some kind of EPROM if you wish. > > The important point is that we can (and arguably _should_ since it keeps > us honest!) make these ACPI tables RAMBlocks fixed-size per machine > type. See the patches I posted around late September/early October. > There is no need to support auto-fixing of the RAMBlock's sizes. > > Paolo I'm not sure I buy that we should. ACPI bytecode can express identical interfaces in different ways. Even just recompiling ACPI from source can give you a different binary, same is true for a minor change in ACPI code. Migrating between two almost identical builds from qemu seems a very reasonable thing to do. -- MST