Re: [Qemu-devel] [PATCH for-2.1 2/2] acpi: mark ACPI tables ROM blob as extend-able on migration

["Michael S. Tsirkin" <mst@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