Re: [Qemu-devel] [PATCH 0/4] acpi: move common parts of the SSDT to the DSDT (and preview of things to come)

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Dec 24, 2014 at 03:43:41PM +0100, Paolo Bonzini wrote:
> 
> 
> On 24/12/2014 15:19, Michael S. Tsirkin wrote:
> > So I'll have to review in detail, overall the patches
> > do look pretty clean.
> 
> Q35 is broken though (GArray resizing messes up the tables, fixed
> locally and caught by bios-tables-test even before trying it out!).  I
> hope to send out the fixed version on Saturday (time ticking before
> vacation).
> 
> > Given the amount of pain caused by cross version migration
> > issues, I am inclined to do both: arrange code in a way
> > that makes keeping things constant easier, and have
> > some solutions for the inevitable time when we'll find we
> > have to change things we didn't expect.
> > Defense in depth, if you like.
> > Makes sense?
> 
> It certainly does.  I am only a bit wary because your patches are
> basically a workaround (as hinted by the fact that the resulting RSDP is
> corrupted---which doesn't matter much in practice, but it's still a red
> flashing light!).

Well seen in that light, your patches are also basically a work-around :)


> So I still would like to see how stuff looks like after Igor's code is
> merged.

Hmm apply them to you tree and see? Do you need my help to put them
on a temporary branch?

>  Until we actually trim the size of the ACPI tables (patch 7),
> we do no better / no worse than released versions of QEMU.

Right, and actually trimming them seems much safer to me if
we can actually guarantee that possible need to increase them
back in the future will not break things.


> And once Igor's code is merged, we actually have an idea of what is left
> in the SSDT, and how tricky that code is.  "Not tricky at all" is
> perhaps a bit optimistic, a more realistic hope is "not any more tricky
> than what we do for devices".
> 
> In other words, it's only tricky now because it's new.  We had all sorts
> of false starts, but the my patches and Igor's provide enough separation
> (mine: fixed vs. variable; Igor's: ASL vs. C) that the future should
> reserve less surprises.
> 
> I will still review your patches, of course.
> 
> Paolo

As the one who has to maintain this mess, I think my peace of mind has
some value :) So from the PC side of things I'm inclined to merge this
even if it proves to be not useful - it's there if we need it, and at
least it does not break things.

But I do want your review of the core bits, since these things
are tricky to stress-test properly.

-- 
MST