[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/4] acpi: move common parts of the SSDT to the
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH 0/4] acpi: move common parts of the SSDT to the DSDT (and preview of things to come) |
Date: |
Wed, 24 Dec 2014 18:15:26 +0200 |
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
- [Qemu-devel] [PATCH 3/4] pc: move common parts of the DSDT to dsdt-common, (continued)
- [Qemu-devel] [PATCH 3/4] pc: move common parts of the DSDT to dsdt-common, Paolo Bonzini, 2014/12/24
- [Qemu-devel] [PATCH 1/4] pc: append ssdt-misc.dsl to the DSDT, Paolo Bonzini, 2014/12/24
- [Qemu-devel] [PATCH 4/4] pc: merge DSDT common parts into acpi-dsdt-common.dsl, Paolo Bonzini, 2014/12/24
- [Qemu-devel] [PATCH 5/4] pc: introduce new ACPI table sizing algorithm, Paolo Bonzini, 2014/12/24
- [Qemu-devel] [PATCH 2/4] pc: rename ssdt-misc to dsdt-common, Paolo Bonzini, 2014/12/24
- [Qemu-devel] [PATCH 6/4] pc: clean up pre-2.1 compatibility code, Paolo Bonzini, 2014/12/24
- [Qemu-devel] [PATCH 7/4] pc: go back to smaller ACPI tables, Paolo Bonzini, 2014/12/24
- Re: [Qemu-devel] [PATCH 0/4] acpi: move common parts of the SSDT to the DSDT (and preview of things to come), Paolo Bonzini, 2014/12/24
- 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, 2014/12/24