Re: [Qemu-devel] [PATCH 25/74] pc: acpi: memhp: prepare context in SSDT for moving memhp DSDT code

[Marcel Apfelbaum]

On 12/17/2015 03:47 PM, Igor Mammedov wrote:
> On Thu, 17 Dec 2015 14:14:28 +0200
> Marcel Apfelbaum <address@hidden> wrote:
>
> > On 12/16/2015 04:25 PM, Igor Mammedov wrote:
> > > On Wed, 16 Dec 2015 15:25:46 +0200
> > > Marcel Apfelbaum <address@hidden> wrote:
> > >
> > > > On 12/10/2015 01:41 AM, Igor Mammedov wrote:
> > > > > Signed-off-by: Igor Mammedov <address@hidden>
> > > > > ---
> > > > >     hw/acpi/Makefile.objs               |  2 +-
> > > > >     hw/acpi/memory_hotplug_acpi_table.c | 40
> > > > > +++++++++++++++++++++++++++++++++++++
> > > > > hw/i386/acpi-build.c                |  3 +++
> > > > > include/hw/acpi/memory_hotplug.h    |  4 ++++ 4 files changed, 48
> > > > > insertions(+), 1 deletion(-) create mode 100644
> > > > > hw/acpi/memory_hotplug_acpi_table.c
> > > > >
> > > > > diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
> > > > > index 7d3230c..c04064e 100644
> > > > > --- a/hw/acpi/Makefile.objs
> > > > > +++ b/hw/acpi/Makefile.objs
> > > > > @@ -1,7 +1,7 @@
> > > > >     common-obj-$(CONFIG_ACPI_X86) += core.o piix4.o pcihp.o
> > > > >     common-obj-$(CONFIG_ACPI_X86_ICH) += ich9.o tco.o
> > > > >     common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu_hotplug.o
> > > > > -common-obj-$(CONFIG_ACPI_MEMORY_HOTPLUG) += memory_hotplug.o
> > > > > +common-obj-$(CONFIG_ACPI_MEMORY_HOTPLUG) += memory_hotplug.o
> > > > > memory_hotplug_acpi_table.o common-obj-$(CONFIG_ACPI) +=
> > > > > acpi_interface.o common-obj-$(CONFIG_ACPI) += bios-linker-loader.o
> > > > >     common-obj-$(CONFIG_ACPI) += aml-build.o
> > > > > diff --git a/hw/acpi/memory_hotplug_acpi_table.c
> > > > > b/hw/acpi/memory_hotplug_acpi_table.c new file mode 100644
> > > > > index 0000000..25bbf5e
> > > > > --- /dev/null
> > > > > +++ b/hw/acpi/memory_hotplug_acpi_table.c
> > > > > @@ -0,0 +1,40 @@
> > > > > +/*
> > > > > + * Memory hotplug AML code of DSDT ACPI table
> > > >
> > > > You are advertising as part of the DSDT code, but you are putting in
> > > > SSDT, right? By the way, maybe the answer is clear, but why are you
> > > > moving it to SSDT?
> > > There could be only one instance of DSDT and I temporarily put
> > > converted DSDT bits in SSDT until conversion is complete.
> >
> > I understand there can only be one DSDT table, but can't we have a "hybrid"
> > DSDT made from both asl files and C code?
> I've considered that and it's a little painful but possible
> to do for some parts of DSDT if ASL moved out from beginning/end
> of template. However when it comes to moving parts of ASL from
> the middle of template due to dependencies it all becomes way to
> too complicated or I'll have to convert almost ALL of DSDT in one patch,
> but that, even though verifiable via ACPI tests, won't be human
> review-able chunk.

Yes, I thought it would not be easy.

> > > > Last thing, from this patch forward (until maybe the last one) make
> > > > check fails, right? (Specifically the acpi tests)
> > > yes, starting from this patch and upto 72nd acpi test fails since
> > > patches move DSDT bits into SSDT.
> >
> > This can be a problem.
> > I am thinking of 2 solutions:
> > 1. Disable the iasl tests on patch 1 and re-enable it on patch 73.
> > 2. Go for a "hybrid" DSDT.
> >
> > If (2) is too complicated, the implication is that all this series
> > must be taken atomically. Of course, (1) or some other idea is needed.
> >
> > What do you think?
> as #2 too complicated, we could go with #1 but I don't think
> it will gain us much if anything.
>
> Yep, untill whole series is applied ACPI tests will not pass,
> that will affect bisection with 'make check' on each step
> but developers can deal with it and just ignore failed tests.

Here I don't agree, think about different tests not working from
different reasons, and make check failing because all kind of series,
how the developer would know not to take it in consideration? (and what to 
take?)

> Main goal was to make conversion and make sure that at the end
> of day it hasn't regressed tests.
> I don't think that putting much more efforts to keep interseries
> ACPI tests check passing is worth of an effort.

I personally think that is a little effort to disable the acpi test
in order to keep 'make check' clean.
However, we can ask for another opinion, I CC-ed Michael as the PC maintainer.

Thanks,
Marcel

[...]