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
