From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a5d:6089:0:0:0:0:0 with SMTP id w9csp1323311wrt; Tue, 27 Nov 2018 06:12:55 -0800 (PST) X-Google-Smtp-Source: AFSGD/XkPCf/rW/k8qvyQ3sefd/qyO2e1j6VrgJF6LKp3PER192xnuB3ry1wrlDGPtwF5cJAbd0q X-Received: by 2002:a81:5153:: with SMTP id f80mr28806638ywb.90.1543327975127; Tue, 27 Nov 2018 06:12:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543327975; cv=none; d=google.com; s=arc-20160816; b=wKQUdllSAnznCz4PI0F+US8xKsA2aaoLtivYGTSVwZE71ydh9JzbyK5VtLmKaLgFk5 GyvRlGkfcJSMPmyyQ8bh422crs2gXKTJkKWgavjkkwdq3919S00Rm1JUZ5G6En7cBwKy eAcVodgBn2mO1lA3gubN2lspAqKPiJMBxvNMQlMJbLiqP3Ec9uywtDElhAZgUnkSgTC7 qD6bB1gBFBxIkoUXTu9XW+4soj4JGirm6ZqvwX1dSLra4d6R5lc0x+pZtRTPCYKjoLMh FGY0Y/Z3Ufc7YL0CJBkmP4SjxLndQyr6M3BFN09WRAO2RF7mBcRUauVJyzVrK3ye4HE/ YrhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject :content-transfer-encoding:mime-version:references:in-reply-to :message-id:to:from:date; bh=K9iyqG+dkrCdpxj9ROkA8ZcB5ooB077Em0B2oUzfUYE=; b=OAe4RK7s+4xpHvWUaeer1mpuVl2lMPrm75iENzXZOgtiaSBdmZnQI/60nBoJHGFvnY 2oDaooIPijPF6UTBgFQp6DW0qOTeeD+UBRVNbo0ZefN2rP8wxP+cPPe6a253DEMfjKvc RDtkyxREvhMTO8EgO1BbADsihGYrtxUlFEbynjFu+BiVUfLshlOLLgBYVjwuG5YbwY3Z FR9OEPrxnrUPBGk4/jClvuL+1kjfT3zeHmwgQ75pD/IWllxKzr/tXHQkJbbPmJoTxiOu eTT/4yOnKRjwgryI4C1F78mkbtXQ8cHhlskYxYKreqfMfPSYaGJfpVai51EofKSC+mW2 cj3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org. [2001:4830:134:3::11]) by mx.google.com with ESMTPS id n204-v6si2846701ybg.13.2018.11.27.06.12.54 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 27 Nov 2018 06:12:55 -0800 (PST) Received-SPF: pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) client-ip=2001:4830:134:3::11; Authentication-Results: mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from localhost ([::1]:42650 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRe6g-0003oP-Hc for alex.bennee@linaro.org; Tue, 27 Nov 2018 09:12:54 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRe2M-0000bN-KX for qemu-arm@nongnu.org; Tue, 27 Nov 2018 09:08:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRe2I-0008Gz-T3 for qemu-arm@nongnu.org; Tue, 27 Nov 2018 09:08:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47344) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gRe2G-0007Ky-Pq; Tue, 27 Nov 2018 09:08:22 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2A6A0D780E; Tue, 27 Nov 2018 14:08:15 +0000 (UTC) Received: from localhost (unknown [10.43.2.182]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1A63260C4C; Tue, 27 Nov 2018 14:08:09 +0000 (UTC) Date: Tue, 27 Nov 2018 15:08:08 +0100 From: Igor Mammedov To: Samuel Ortiz Message-ID: <20181127150808.1c719882@redhat.com> In-Reply-To: <20181121235721.GE4450@caravaggio> References: <20181105014047.26447-1-sameo@linux.intel.com> <20181105014047.26447-21-sameo@linux.intel.com> <20181116170226.35385388@redhat.com> <20181121235721.GE4450@caravaggio> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 27 Nov 2018 14:08:15 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v5 20/24] hw: acpi: Define ACPI tables builder interface X-BeenThere: qemu-arm@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Shannon Zhao , qemu-arm@nongnu.org, Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson Errors-To: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org Sender: "Qemu-arm" X-TUID: AStPNweTNF3k On Thu, 22 Nov 2018 00:57:21 +0100 Samuel Ortiz wrote: > On Fri, Nov 16, 2018 at 05:02:26PM +0100, Igor Mammedov wrote: > > On Mon, 5 Nov 2018 02:40:43 +0100 > > Samuel Ortiz wrote: > > > > > In order to decouple ACPI APIs from specific machine types, we are > > > creating an ACPI builder interface that each ACPI platform can choose to > > > implement. > > > This way, a new machine type can re-use the high level ACPI APIs and > > > define some custom table build methods, without having to duplicate most > > > of the existing implementation only to add small variations to it. > > I'm not sure about motivation behind so high APIs, > > what obvious here is an extra level of indirection for not clear gain. > > > > Yep using table callbacks, one can attempt to generalize > > acpi_setup() and help boards to decide which tables do not build > > (MCFG comes to the mind). But I'm not convinced that acpi_setup() > > could be cleanly generalized as a whole (probably some parts but > > not everything) > It's more about generalizing acpi_build(), and then having one > acpi_setup for non hardware-reduced ACPI and a acpi_reduced_setup() for > hardware-reduced. > > Right now there's no generalization at all but with this patch we could > already use the same acpi_reduced_setup() implementation for both arm > and i386/virt. > > > so it's minor benefit for extra headache of > > figuring out what callback will be actually called when reading code. > This is the same complexity that already exists for essentially all > current interfaces. in case of callback vs plain function call, I'd choose the later if it does the job and resort to the former when I have to. > > However if board needs a slightly different table, it will have to > > duplicate an exiting one and then modify to suit its needs. > > > > to me it pretty much looks the same as calling build_foo() > > we use now but with an extra indirection level and then > > duplicating the later for usage in another board in slightly > > different manner. > I believe what you're trying to say is that this abstraction may be > useful but you're arguing the granularity is not properly defined? Am I > getting this right? yep, something along those lines. So far it's not useful much if at all. So I'll not introduce it for now and try to get by with plain functions calls. Later we might add fine-grained callbacks on case by case basis (like 'adevc->madt_cpu') where it's possible to generalize. > Cheers, > Samuel. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Mammedov Subject: Re: [Qemu-devel] [PATCH v5 20/24] hw: acpi: Define ACPI tables builder interface Date: Tue, 27 Nov 2018 15:08:08 +0100 Message-ID: <20181127150808.1c719882@redhat.com> References: <20181105014047.26447-1-sameo@linux.intel.com> <20181105014047.26447-21-sameo@linux.intel.com> <20181116170226.35385388@redhat.com> <20181121235721.GE4450@caravaggio> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1gRe2D-0008UY-7b for xen-devel@lists.xenproject.org; Tue, 27 Nov 2018 14:08:17 +0000 In-Reply-To: <20181121235721.GE4450@caravaggio> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" To: Samuel Ortiz Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Shannon Zhao , qemu-arm@nongnu.org, Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson List-Id: xen-devel@lists.xenproject.org T24gVGh1LCAyMiBOb3YgMjAxOCAwMDo1NzoyMSArMDEwMApTYW11ZWwgT3J0aXogPHNhbWVvQGxp bnV4LmludGVsLmNvbT4gd3JvdGU6Cgo+IE9uIEZyaSwgTm92IDE2LCAyMDE4IGF0IDA1OjAyOjI2 UE0gKzAxMDAsIElnb3IgTWFtbWVkb3Ygd3JvdGU6Cj4gPiBPbiBNb24sICA1IE5vdiAyMDE4IDAy OjQwOjQzICswMTAwCj4gPiBTYW11ZWwgT3J0aXogPHNhbWVvQGxpbnV4LmludGVsLmNvbT4gd3Jv dGU6Cj4gPiAgIAo+ID4gPiBJbiBvcmRlciB0byBkZWNvdXBsZSBBQ1BJIEFQSXMgZnJvbSBzcGVj aWZpYyBtYWNoaW5lIHR5cGVzLCB3ZSBhcmUKPiA+ID4gY3JlYXRpbmcgYW4gQUNQSSBidWlsZGVy IGludGVyZmFjZSB0aGF0IGVhY2ggQUNQSSBwbGF0Zm9ybSBjYW4gY2hvb3NlIHRvCj4gPiA+IGlt cGxlbWVudC4KPiA+ID4gVGhpcyB3YXksIGEgbmV3IG1hY2hpbmUgdHlwZSBjYW4gcmUtdXNlIHRo ZSBoaWdoIGxldmVsIEFDUEkgQVBJcyBhbmQKPiA+ID4gZGVmaW5lIHNvbWUgY3VzdG9tIHRhYmxl IGJ1aWxkIG1ldGhvZHMsIHdpdGhvdXQgaGF2aW5nIHRvIGR1cGxpY2F0ZSBtb3N0Cj4gPiA+IG9m IHRoZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiBvbmx5IHRvIGFkZCBzbWFsbCB2YXJpYXRpb25z IHRvIGl0LiAgCj4gPiBJJ20gbm90IHN1cmUgYWJvdXQgbW90aXZhdGlvbiBiZWhpbmQgc28gaGln aCBBUElzLAo+ID4gd2hhdCBvYnZpb3VzIGhlcmUgaXMgYW4gZXh0cmEgbGV2ZWwgb2YgaW5kaXJl Y3Rpb24gZm9yIG5vdCBjbGVhciBnYWluLgo+ID4gCj4gPiBZZXAgdXNpbmcgdGFibGUgY2FsbGJh Y2tzLCBvbmUgY2FuIGF0dGVtcHQgdG8gZ2VuZXJhbGl6ZQo+ID4gYWNwaV9zZXR1cCgpIGFuZCBo ZWxwIGJvYXJkcyB0byBkZWNpZGUgd2hpY2ggdGFibGVzIGRvIG5vdCBidWlsZAo+ID4gKE1DRkcg Y29tZXMgdG8gdGhlIG1pbmQpLiBCdXQgSSdtIG5vdCBjb252aW5jZWQgdGhhdCBhY3BpX3NldHVw KCkKPiA+IGNvdWxkIGJlIGNsZWFubHkgZ2VuZXJhbGl6ZWQgYXMgYSB3aG9sZSAocHJvYmFibHkg c29tZSBwYXJ0cyBidXQKPiA+IG5vdCBldmVyeXRoaW5nKSAgCj4gSXQncyBtb3JlIGFib3V0IGdl bmVyYWxpemluZyBhY3BpX2J1aWxkKCksIGFuZCB0aGVuIGhhdmluZyBvbmUKPiBhY3BpX3NldHVw IGZvciBub24gaGFyZHdhcmUtcmVkdWNlZCBBQ1BJIGFuZCBhIGFjcGlfcmVkdWNlZF9zZXR1cCgp IGZvcgo+IGhhcmR3YXJlLXJlZHVjZWQuCj4gCj4gUmlnaHQgbm93IHRoZXJlJ3Mgbm8gZ2VuZXJh bGl6YXRpb24gYXQgYWxsIGJ1dCB3aXRoIHRoaXMgcGF0Y2ggd2UgY291bGQKPiBhbHJlYWR5IHVz ZSB0aGUgc2FtZSBhY3BpX3JlZHVjZWRfc2V0dXAoKSBpbXBsZW1lbnRhdGlvbiBmb3IgYm90aCBh cm0KPiBhbmQgaTM4Ni92aXJ0Lgo+IAo+ID4gc28gaXQncyBtaW5vciBiZW5lZml0IGZvciBleHRy YSBoZWFkYWNoZSBvZgo+ID4gZmlndXJpbmcgb3V0IHdoYXQgY2FsbGJhY2sgd2lsbCBiZSBhY3R1 YWxseSBjYWxsZWQgd2hlbiByZWFkaW5nIGNvZGUuICAKPiBUaGlzIGlzIHRoZSBzYW1lIGNvbXBs ZXhpdHkgdGhhdCBhbHJlYWR5IGV4aXN0cyBmb3IgZXNzZW50aWFsbHkgYWxsCj4gY3VycmVudCBp bnRlcmZhY2VzLgppbiBjYXNlIG9mIGNhbGxiYWNrIHZzIHBsYWluIGZ1bmN0aW9uIGNhbGwsIEkn ZCBjaG9vc2UgdGhlIGxhdGVyCmlmIGl0IGRvZXMgdGhlIGpvYiBhbmQgcmVzb3J0IHRvIHRoZSBm b3JtZXIgd2hlbiBJIGhhdmUgdG8uCiAKPiA+IEhvd2V2ZXIgaWYgYm9hcmQgbmVlZHMgYSBzbGln aHRseSBkaWZmZXJlbnQgdGFibGUsIGl0IHdpbGwgaGF2ZSB0bwo+ID4gZHVwbGljYXRlIGFuIGV4 aXRpbmcgb25lIGFuZCB0aGVuIG1vZGlmeSB0byBzdWl0IGl0cyBuZWVkcy4KPiA+IAo+ID4gdG8g bWUgaXQgcHJldHR5IG11Y2ggbG9va3MgdGhlIHNhbWUgYXMgY2FsbGluZyBidWlsZF9mb28oKQo+ ID4gd2UgdXNlIG5vdyBidXQgd2l0aCBhbiBleHRyYSBpbmRpcmVjdGlvbiBsZXZlbCBhbmQgdGhl bgo+ID4gZHVwbGljYXRpbmcgdGhlIGxhdGVyIGZvciB1c2FnZSBpbiBhbm90aGVyIGJvYXJkIGlu IHNsaWdodGx5Cj4gPiBkaWZmZXJlbnQgbWFubmVyLiAgCj4gSSBiZWxpZXZlIHdoYXQgeW91J3Jl IHRyeWluZyB0byBzYXkgaXMgdGhhdCB0aGlzIGFic3RyYWN0aW9uIG1heSBiZQo+IHVzZWZ1bCBi dXQgeW91J3JlIGFyZ3VpbmcgdGhlIGdyYW51bGFyaXR5IGlzIG5vdCBwcm9wZXJseSBkZWZpbmVk PyBBbSBJCj4gZ2V0dGluZyB0aGlzIHJpZ2h0Pwp5ZXAsIHNvbWV0aGluZyBhbG9uZyB0aG9zZSBs aW5lcy4gU28gZmFyIGl0J3Mgbm90IHVzZWZ1bCBtdWNoIGlmIGF0IGFsbC4KU28gSSdsbCBub3Qg aW50cm9kdWNlIGl0IGZvciBub3cgYW5kIHRyeSB0byBnZXQgYnkgd2l0aCBwbGFpbiBmdW5jdGlv bnMKY2FsbHMuIExhdGVyIHdlIG1pZ2h0IGFkZCBmaW5lLWdyYWluZWQgY2FsbGJhY2tzIG9uIGNh c2UgYnkgY2FzZSBiYXNpcwoobGlrZSAnYWRldmMtPm1hZHRfY3B1Jykgd2hlcmUgaXQncyBwb3Nz aWJsZSB0byBnZW5lcmFsaXplLgogCj4gQ2hlZXJzLAo+IFNhbXVlbC4KCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0 Clhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwczovL2xpc3RzLnhlbnByb2plY3Qu b3JnL21haWxtYW4vbGlzdGluZm8veGVuLWRldmVs From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRe2S-0000iS-Fu for qemu-devel@nongnu.org; Tue, 27 Nov 2018 09:08:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRe2N-0000VU-Np for qemu-devel@nongnu.org; Tue, 27 Nov 2018 09:08:32 -0500 Date: Tue, 27 Nov 2018 15:08:08 +0100 From: Igor Mammedov Message-ID: <20181127150808.1c719882@redhat.com> In-Reply-To: <20181121235721.GE4450@caravaggio> References: <20181105014047.26447-1-sameo@linux.intel.com> <20181105014047.26447-21-sameo@linux.intel.com> <20181116170226.35385388@redhat.com> <20181121235721.GE4450@caravaggio> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 20/24] hw: acpi: Define ACPI tables builder interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Samuel Ortiz Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Shannon Zhao , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , Richard Henderson On Thu, 22 Nov 2018 00:57:21 +0100 Samuel Ortiz wrote: > On Fri, Nov 16, 2018 at 05:02:26PM +0100, Igor Mammedov wrote: > > On Mon, 5 Nov 2018 02:40:43 +0100 > > Samuel Ortiz wrote: > > > > > In order to decouple ACPI APIs from specific machine types, we are > > > creating an ACPI builder interface that each ACPI platform can choose to > > > implement. > > > This way, a new machine type can re-use the high level ACPI APIs and > > > define some custom table build methods, without having to duplicate most > > > of the existing implementation only to add small variations to it. > > I'm not sure about motivation behind so high APIs, > > what obvious here is an extra level of indirection for not clear gain. > > > > Yep using table callbacks, one can attempt to generalize > > acpi_setup() and help boards to decide which tables do not build > > (MCFG comes to the mind). But I'm not convinced that acpi_setup() > > could be cleanly generalized as a whole (probably some parts but > > not everything) > It's more about generalizing acpi_build(), and then having one > acpi_setup for non hardware-reduced ACPI and a acpi_reduced_setup() for > hardware-reduced. > > Right now there's no generalization at all but with this patch we could > already use the same acpi_reduced_setup() implementation for both arm > and i386/virt. > > > so it's minor benefit for extra headache of > > figuring out what callback will be actually called when reading code. > This is the same complexity that already exists for essentially all > current interfaces. in case of callback vs plain function call, I'd choose the later if it does the job and resort to the former when I have to. > > However if board needs a slightly different table, it will have to > > duplicate an exiting one and then modify to suit its needs. > > > > to me it pretty much looks the same as calling build_foo() > > we use now but with an extra indirection level and then > > duplicating the later for usage in another board in slightly > > different manner. > I believe what you're trying to say is that this abstraction may be > useful but you're arguing the granularity is not properly defined? Am I > getting this right? yep, something along those lines. So far it's not useful much if at all. So I'll not introduce it for now and try to get by with plain functions calls. Later we might add fine-grained callbacks on case by case basis (like 'adevc->madt_cpu') where it's possible to generalize. > Cheers, > Samuel.