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: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