From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlhrP-0002sD-CF for qemu-devel@nongnu.org; Tue, 04 Nov 2014 12:25:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlhrJ-0003I4-0P for qemu-devel@nongnu.org; Tue, 04 Nov 2014 12:25:39 -0500 Date: Tue, 4 Nov 2014 19:25:26 +0200 From: "Michael S. Tsirkin" Message-ID: <20141104172526.GA32696@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> <20141104164610.GA32459@redhat.com> <545904C2.1040300@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <545904C2.1040300@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:54:26PM +0100, Paolo Bonzini wrote: > On 04/11/2014 17:46, Michael S. Tsirkin wrote: > > 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. > > > > 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. > > Yes, identical ACPI blocks are just a sufficient condition, not a > necessary one. But it's very easy to enforce it, and it's what the > acpi-tables-test already checks. It makes sense to me to stick with it. > > (Regarding recompilation with a different iasl version, SSDT blocks are > simple enough that I think we can just build them in C code. We're > already doing it for the much more complicated PCI bridge hotplug > interface. BTW, can you pick up at least the patch to move the memory > hotplug device from SSDT to DSDT?). > > Paolo I'm not against that - does this have value by itself? -- MST