From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9bti-0001uu-7s for qemu-devel@nongnu.org; Thu, 17 Dec 2015 11:59:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9btd-0001ov-Ra for qemu-devel@nongnu.org; Thu, 17 Dec 2015 11:59:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9btd-0001oq-JS for qemu-devel@nongnu.org; Thu, 17 Dec 2015 11:59:17 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C038719F23B for ; Thu, 17 Dec 2015 16:59:16 +0000 (UTC) Date: Thu, 17 Dec 2015 17:59:14 +0100 From: Igor Mammedov Message-ID: <20151217175914.1b911787@nial.brq.redhat.com> In-Reply-To: <5672C2E7.6030402@redhat.com> References: <1449704528-289297-1-git-send-email-imammedo@redhat.com> <1449704528-289297-26-git-send-email-imammedo@redhat.com> <5671665A.8000603@gmail.com> <20151216152555.01a91e12@igors-macbook-pro.local> <5672A724.9010800@redhat.com> <20151217144750.06579c1b@nial.brq.redhat.com> <5672C2E7.6030402@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 25/74] pc: acpi: memhp: prepare context in SSDT for moving memhp DSDT code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" On Thu, 17 Dec 2015 16:12:55 +0200 Marcel Apfelbaum wrote: > On 12/17/2015 03:47 PM, Igor Mammedov wrote: > > On Thu, 17 Dec 2015 14:14:28 +0200 > > Marcel Apfelbaum wrote: > > > >> On 12/16/2015 04:25 PM, Igor Mammedov wrote: > >>> On Wed, 16 Dec 2015 15:25:46 +0200 > >>> Marcel Apfelbaum wrote: > >>> > >>>> On 12/10/2015 01:41 AM, Igor Mammedov wrote: > >>>>> Signed-off-by: Igor Mammedov > >>>>> --- > >>>>> 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. So far with patches/series, that are changing SSDT or DSDT and obviously breaking ACPI test, policy was submit it without updating test and let maintainer to update ACPI blobs in test after series has been applied, i.e. not disabling it. I sometimes post an additional patch, that updates ACPI blobs in test as the last in series. But that patch however could be easily discarded or be obsoleted because some another patch changing ACPI tables was committed before and maintainer has to update test himself. > > Thanks, > Marcel > > [...] >