From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a5d:6089:0:0:0:0:0 with SMTP id w9csp1854872wrt; Fri, 23 Nov 2018 03:04:37 -0800 (PST) X-Google-Smtp-Source: AJdET5cAqJ+atG7g00sax8DAXgdpOSeNzQGpfup2IXe4wKNii5NKu0jPi6fFXG7OhtzEKdP7eHMU X-Received: by 2002:aed:23c5:: with SMTP id k5mr13812532qtc.39.1542971077322; Fri, 23 Nov 2018 03:04:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542971077; cv=none; d=google.com; s=arc-20160816; b=qpXv35/L6lRXonScDJDg7KEnIp04Jz2cuMLTaHf4HG6SDC51jNVqAgPBl5l+mlHvh9 uOuxEVJlFXR+U659v/5D2urw5Xpk9s+nGOAoijgd0R9poB2THyGuw/LIoZDnLvr9N2kD FdqEgwjqTUb+toBgStjS9HoZVNN3HvvxvvX2Wc6Hm/4Bepdckc1eXp2PVnFPQqN7FBBJ EDNRsuBozl8o+lcfDcQbGq4OXt/1Q5DKvq8AjtlB+RUu1E3c+Ixakdw6RVQdli+h4h54 rEYiN+qH2K6d44PN10lml608/lT5gZd10JsxFbaWJGmDVIoWoVv+S3C8w0s34Ar3DXWo /SgA== 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=f255J9trikByGhKOgZdaT226yS1zCW9q77muEEQ9fGs=; b=xuyfUThXmg53TvpLttxEaN8YK+CFYVbG3uFhkpqgH7awrSs1DmQvDxy2v4f7+poelK 74zuqqeMqLVOt+Yb69VIklVW0XrC+dD/8REkhsX7yoBPhMRoCJJ3oFke+tBbIpESSF67 9gJbPM+G4uSjvnTZ/UjDMu7O0ebvkWRlvuvybpG9Hk0krVWAi3fT2uJtDwWMugPFBWBV hb2vf0U2hyCIZ5Kqik0rQqjK87SbtTotXSJdVPgnTBtWwH8BnUeBxLU22jhJ6sa80+hK Bfc9mhA6O+3izfbo+FWJIwL58ucZOJ66dw2S3iE4UxwhQcMrqtRE8U1Q1lzEXV7dqs1r WUzg== 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 f196si7729860qka.61.2018.11.23.03.04.37 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 23 Nov 2018 03:04:37 -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]:51617 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gQ9GG-00083v-Lt for alex.bennee@linaro.org; Fri, 23 Nov 2018 06:04:36 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gQ9Fv-0007yM-BS for qemu-arm@nongnu.org; Fri, 23 Nov 2018 06:04:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gQ9Fr-0005eS-94 for qemu-arm@nongnu.org; Fri, 23 Nov 2018 06:04:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50424) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gQ9Fq-0005bm-VB; Fri, 23 Nov 2018 06:04:11 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 289C836807; Fri, 23 Nov 2018 11:04:10 +0000 (UTC) Received: from localhost (unknown [10.43.2.182]) by smtp.corp.redhat.com (Postfix) with ESMTP id 543B15D763; Fri, 23 Nov 2018 11:04:07 +0000 (UTC) Date: Fri, 23 Nov 2018 12:04:05 +0100 From: Igor Mammedov To: Samuel Ortiz Message-ID: <20181123120405.4b94a220@redhat.com> In-Reply-To: <20181121231217.GA4450@caravaggio> References: <20181105014047.26447-1-sameo@linux.intel.com> <20181105014047.26447-12-sameo@linux.intel.com> <20181114115537.3357921b@redhat.com> <20181121231217.GA4450@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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 23 Nov 2018 11:04:10 +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 11/24] hw: acpi: Export and generalize the PCI host AML API 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: Yang Zhong , Peter Maydell , Stefano Stabellini , Eduardo Habkost , Rob Bradford , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Shannon Zhao , qemu-arm@nongnu.org, Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , Richard Henderson Errors-To: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org Sender: "Qemu-arm" X-TUID: PHc9p1FoCRWb On Thu, 22 Nov 2018 00:12:17 +0100 Samuel Ortiz wrote: > Hi Igor, > > On Wed, Nov 14, 2018 at 11:55:37AM +0100, Igor Mammedov wrote: > > On Mon, 5 Nov 2018 02:40:34 +0100 > > Samuel Ortiz wrote: > > > > > From: Yang Zhong > > > > > > The AML build routines for the PCI host bridge and the corresponding > > > DSDT addition are neither x86 nor PC machine type specific. > > > We can move them to the architecture agnostic hw/acpi folder, and by > > > carrying all the needed information through a new AcpiPciBus structure, > > > we can make them PC machine type independent. > > > > I'm don't know anything about PCI, but functional changes doesn't look > > correct to me. > > > > See more detailed comments below. > > > > Marcel, > > could you take a look on this patch (in particular main csr changes), pls? > > > > > > > > Signed-off-by: Yang Zhong > > > Signed-off-by: Rob Bradford > > > Signed-off-by: Samuel Ortiz > > > --- > > > include/hw/acpi/aml-build.h | 8 ++ > > > hw/acpi/aml-build.c | 157 ++++++++++++++++++++++++++++++++++++ > > > hw/i386/acpi-build.c | 115 ++------------------------ > > > 3 files changed, 173 insertions(+), 107 deletions(-) > > > > > > diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h > > > index fde2785b9a..1861e37ebf 100644 > > > --- a/include/hw/acpi/aml-build.h > > > +++ b/include/hw/acpi/aml-build.h > > > @@ -229,6 +229,12 @@ typedef struct AcpiMcfgInfo { > > > uint32_t mcfg_size; > > > } AcpiMcfgInfo; > > > > > > +typedef struct AcpiPciBus { > > > + PCIBus *pci_bus; > > > + Range *pci_hole; > > > + Range *pci_hole64; > > > +} AcpiPciBus; > > Again, this and all below is not aml-build material. > > Consider adding/using pci specific acpi file for it. > > > > Also even though pci AML in arm/virt is to a large degree a subset > > of x86 target and it would be much better to unify ARM part with x86, > > it probably will be to big/complex of a change if we take on it in > > one go. > > > > So not to derail you from the goal too much, we probably should > > generalize this a little bit less, limiting refactoring to x86 > > target for now. > So keeping it under i386 means it won't be accessible through hw/acpi/, > which means we won't be able to have a generic hw/acpi/reduced.c > implementation. From our perspective, this is the problem with keeping > things under i386 because we're not sure yet how much generic it is: It > still won't be shareable for a generic hardware-reduced ACPI > implementation which means we'll have to temporarily have yet another > hardware-reduced ACPI implementation under hw/i386 this time. > I guess this is what Michael meant by keeping some parts of the code > duplicated for now. > > I feel it'd be easier to move those APIs under a shareable location, to > make it easier for ARM to consume it even if it's not entirely generic yet. > But you guys are the maintainers and if you think we should restric the > generalization to x86 only for now, we can go for it. If code is generic (you can reuse it with arm/virt in the same series) then place it in hw/acpi otherwise if it's semi-generic put to hw/i386. If it would be a separate file it would be easier to move it to generic place when we are able to resuse it with arm/virt. > Cheers, > Samuel. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Mammedov Subject: Re: [Qemu-devel] [PATCH v5 11/24] hw: acpi: Export and generalize the PCI host AML API Date: Fri, 23 Nov 2018 12:04:05 +0100 Message-ID: <20181123120405.4b94a220@redhat.com> References: <20181105014047.26447-1-sameo@linux.intel.com> <20181105014047.26447-12-sameo@linux.intel.com> <20181114115537.3357921b@redhat.com> <20181121231217.GA4450@caravaggio> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from us1-rack-dfw2.inumbo.com ([104.130.134.6]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1gQ9Fr-00028v-Ry for xen-devel@lists.xenproject.org; Fri, 23 Nov 2018 11:04:11 +0000 In-Reply-To: <20181121231217.GA4450@caravaggio> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" To: Samuel Ortiz Cc: Yang Zhong , Peter Maydell , Stefano Stabellini , Eduardo Habkost , Rob Bradford , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Shannon Zhao , qemu-arm@nongnu.org, Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , Richard Henderson List-Id: xen-devel@lists.xenproject.org T24gVGh1LCAyMiBOb3YgMjAxOCAwMDoxMjoxNyArMDEwMApTYW11ZWwgT3J0aXogPHNhbWVvQGxp bnV4LmludGVsLmNvbT4gd3JvdGU6Cgo+IEhpIElnb3IsCj4gCj4gT24gV2VkLCBOb3YgMTQsIDIw MTggYXQgMTE6NTU6MzdBTSArMDEwMCwgSWdvciBNYW1tZWRvdiB3cm90ZToKPiA+IE9uIE1vbiwg IDUgTm92IDIwMTggMDI6NDA6MzQgKzAxMDAKPiA+IFNhbXVlbCBPcnRpeiA8c2FtZW9AbGludXgu aW50ZWwuY29tPiB3cm90ZToKPiA+ICAgCj4gPiA+IEZyb206IFlhbmcgWmhvbmcgPHlhbmcuemhv bmdAaW50ZWwuY29tPgo+ID4gPiAKPiA+ID4gVGhlIEFNTCBidWlsZCByb3V0aW5lcyBmb3IgdGhl IFBDSSBob3N0IGJyaWRnZSBhbmQgdGhlIGNvcnJlc3BvbmRpbmcKPiA+ID4gRFNEVCBhZGRpdGlv biBhcmUgbmVpdGhlciB4ODYgbm9yIFBDIG1hY2hpbmUgdHlwZSBzcGVjaWZpYy4KPiA+ID4gV2Ug Y2FuIG1vdmUgdGhlbSB0byB0aGUgYXJjaGl0ZWN0dXJlIGFnbm9zdGljIGh3L2FjcGkgZm9sZGVy LCBhbmQgYnkKPiA+ID4gY2FycnlpbmcgYWxsIHRoZSBuZWVkZWQgaW5mb3JtYXRpb24gdGhyb3Vn aCBhIG5ldyBBY3BpUGNpQnVzIHN0cnVjdHVyZSwKPiA+ID4gd2UgY2FuIG1ha2UgdGhlbSBQQyBt YWNoaW5lIHR5cGUgaW5kZXBlbmRlbnQuICAKPiA+IAo+ID4gSSdtIGRvbid0IGtub3cgYW55dGhp bmcgYWJvdXQgUENJLCBidXQgZnVuY3Rpb25hbCBjaGFuZ2VzIGRvZXNuJ3QgbG9vawo+ID4gY29y cmVjdCB0byBtZS4KPiA+Cj4gPiBTZWUgbW9yZSBkZXRhaWxlZCBjb21tZW50cyBiZWxvdy4KPiA+ IAo+ID4gTWFyY2VsLAo+ID4gY291bGQgeW91IHRha2UgYSBsb29rIG9uIHRoaXMgcGF0Y2ggKGlu IHBhcnRpY3VsYXIgbWFpbiBjc3IgY2hhbmdlcyksIHBscz8KPiA+ICAgCj4gPiA+IAo+ID4gPiBT aWduZWQtb2ZmLWJ5OiBZYW5nIFpob25nIDx5YW5nLnpob25nQGludGVsLmNvbT4KPiA+ID4gU2ln bmVkLW9mZi1ieTogUm9iIEJyYWRmb3JkIDxyb2JlcnQuYnJhZGZvcmRAaW50ZWwuY29tPgo+ID4g PiBTaWduZWQtb2ZmLWJ5OiBTYW11ZWwgT3J0aXogPHNhbWVvQGxpbnV4LmludGVsLmNvbT4KPiA+ ID4gLS0tCj4gPiA+ICBpbmNsdWRlL2h3L2FjcGkvYW1sLWJ1aWxkLmggfCAgIDggKysKPiA+ID4g IGh3L2FjcGkvYW1sLWJ1aWxkLmMgICAgICAgICB8IDE1NyArKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysKPiA+ID4gIGh3L2kzODYvYWNwaS1idWlsZC5jICAgICAgICB8IDExNSAr Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ID4gPiAgMyBmaWxlcyBjaGFuZ2VkLCAxNzMgaW5z ZXJ0aW9ucygrKSwgMTA3IGRlbGV0aW9ucygtKQo+ID4gPiAKPiA+ID4gZGlmZiAtLWdpdCBhL2lu Y2x1ZGUvaHcvYWNwaS9hbWwtYnVpbGQuaCBiL2luY2x1ZGUvaHcvYWNwaS9hbWwtYnVpbGQuaAo+ ID4gPiBpbmRleCBmZGUyNzg1YjlhLi4xODYxZTM3ZWJmIDEwMDY0NAo+ID4gPiAtLS0gYS9pbmNs dWRlL2h3L2FjcGkvYW1sLWJ1aWxkLmgKPiA+ID4gKysrIGIvaW5jbHVkZS9ody9hY3BpL2FtbC1i dWlsZC5oCj4gPiA+IEBAIC0yMjksNiArMjI5LDEyIEBAIHR5cGVkZWYgc3RydWN0IEFjcGlNY2Zn SW5mbyB7Cj4gPiA+ICAgICAgdWludDMyX3QgbWNmZ19zaXplOwo+ID4gPiAgfSBBY3BpTWNmZ0lu Zm87Cj4gPiA+ICAKPiA+ID4gK3R5cGVkZWYgc3RydWN0IEFjcGlQY2lCdXMgewo+ID4gPiArICAg IFBDSUJ1cyAqcGNpX2J1czsKPiA+ID4gKyAgICBSYW5nZSAqcGNpX2hvbGU7Cj4gPiA+ICsgICAg UmFuZ2UgKnBjaV9ob2xlNjQ7Cj4gPiA+ICt9IEFjcGlQY2lCdXM7ICAKPiA+IEFnYWluLCB0aGlz IGFuZCBhbGwgYmVsb3cgaXMgbm90IGFtbC1idWlsZCBtYXRlcmlhbC4KPiA+IENvbnNpZGVyIGFk ZGluZy91c2luZyBwY2kgc3BlY2lmaWMgYWNwaSBmaWxlIGZvciBpdC4KPiA+IAo+ID4gQWxzbyBl dmVuIHRob3VnaCBwY2kgQU1MIGluIGFybS92aXJ0IGlzIHRvIGEgbGFyZ2UgZGVncmVlIGEgc3Vi c2V0Cj4gPiBvZiB4ODYgdGFyZ2V0IGFuZCBpdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byB1bmlm eSBBUk0gcGFydCB3aXRoIHg4NiwKPiA+IGl0IHByb2JhYmx5IHdpbGwgYmUgdG8gYmlnL2NvbXBs ZXggb2YgYSBjaGFuZ2UgaWYgd2UgdGFrZSBvbiBpdCBpbgo+ID4gb25lIGdvLgo+ID4gCj4gPiBT byBub3QgdG8gZGVyYWlsIHlvdSBmcm9tIHRoZSBnb2FsIHRvbyBtdWNoLCB3ZSBwcm9iYWJseSBz aG91bGQKPiA+IGdlbmVyYWxpemUgdGhpcyBhIGxpdHRsZSBiaXQgbGVzcywgbGltaXRpbmcgcmVm YWN0b3JpbmcgdG8geDg2Cj4gPiB0YXJnZXQgZm9yIG5vdy4gIAo+IFNvIGtlZXBpbmcgaXQgdW5k ZXIgaTM4NiBtZWFucyBpdCB3b24ndCBiZSBhY2Nlc3NpYmxlIHRocm91Z2ggaHcvYWNwaS8sCj4g d2hpY2ggbWVhbnMgd2Ugd29uJ3QgYmUgYWJsZSB0byBoYXZlIGEgZ2VuZXJpYyBody9hY3BpL3Jl ZHVjZWQuYwo+IGltcGxlbWVudGF0aW9uLiBGcm9tIG91ciBwZXJzcGVjdGl2ZSwgdGhpcyBpcyB0 aGUgcHJvYmxlbSB3aXRoIGtlZXBpbmcKPiB0aGluZ3MgdW5kZXIgaTM4NiBiZWNhdXNlIHdlJ3Jl IG5vdCBzdXJlIHlldCBob3cgbXVjaCBnZW5lcmljIGl0IGlzOiBJdAo+IHN0aWxsIHdvbid0IGJl IHNoYXJlYWJsZSBmb3IgYSBnZW5lcmljIGhhcmR3YXJlLXJlZHVjZWQgQUNQSQo+IGltcGxlbWVu dGF0aW9uIHdoaWNoIG1lYW5zIHdlJ2xsIGhhdmUgdG8gdGVtcG9yYXJpbHkgaGF2ZSB5ZXQgYW5v dGhlcgo+IGhhcmR3YXJlLXJlZHVjZWQgQUNQSSBpbXBsZW1lbnRhdGlvbiB1bmRlciBody9pMzg2 IHRoaXMgdGltZS4KPiBJIGd1ZXNzIHRoaXMgaXMgd2hhdCBNaWNoYWVsIG1lYW50IGJ5IGtlZXBp bmcgc29tZSBwYXJ0cyBvZiB0aGUgY29kZQo+IGR1cGxpY2F0ZWQgZm9yIG5vdy4KPiAKPiBJIGZl ZWwgaXQnZCBiZSBlYXNpZXIgdG8gbW92ZSB0aG9zZSBBUElzIHVuZGVyIGEgc2hhcmVhYmxlIGxv Y2F0aW9uLCB0bwo+IG1ha2UgaXQgZWFzaWVyIGZvciBBUk0gdG8gY29uc3VtZSBpdCBldmVuIGlm IGl0J3Mgbm90IGVudGlyZWx5IGdlbmVyaWMgeWV0Lgo+IEJ1dCB5b3UgZ3V5cyBhcmUgdGhlIG1h aW50YWluZXJzIGFuZCBpZiB5b3UgdGhpbmsgd2Ugc2hvdWxkIHJlc3RyaWMgdGhlCj4gZ2VuZXJh bGl6YXRpb24gdG8geDg2IG9ubHkgZm9yIG5vdywgd2UgY2FuIGdvIGZvciBpdC4KSWYgY29kZSBp cyBnZW5lcmljICh5b3UgY2FuIHJldXNlIGl0IHdpdGggYXJtL3ZpcnQgaW4gdGhlIHNhbWUgc2Vy aWVzKQp0aGVuIHBsYWNlIGl0IGluIGh3L2FjcGkgb3RoZXJ3aXNlIGlmIGl0J3Mgc2VtaS1nZW5l cmljIHB1dCB0byBody9pMzg2LgpJZiBpdCB3b3VsZCBiZSBhIHNlcGFyYXRlIGZpbGUgaXQgd291 bGQgYmUgZWFzaWVyIHRvIG1vdmUgaXQgdG8gZ2VuZXJpYwpwbGFjZSB3aGVuIHdlIGFyZSBhYmxl IHRvIHJlc3VzZSBpdCB3aXRoIGFybS92aXJ0LgoKIAo+IENoZWVycywKPiBTYW11ZWwuCgoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0cy54 ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33791) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gQ9G6-000875-By for qemu-devel@nongnu.org; Fri, 23 Nov 2018 06:04:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gQ9G1-0005tk-Bp for qemu-devel@nongnu.org; Fri, 23 Nov 2018 06:04:26 -0500 Date: Fri, 23 Nov 2018 12:04:05 +0100 From: Igor Mammedov Message-ID: <20181123120405.4b94a220@redhat.com> In-Reply-To: <20181121231217.GA4450@caravaggio> References: <20181105014047.26447-1-sameo@linux.intel.com> <20181105014047.26447-12-sameo@linux.intel.com> <20181114115537.3357921b@redhat.com> <20181121231217.GA4450@caravaggio> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 11/24] hw: acpi: Export and generalize the PCI host AML API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Samuel Ortiz Cc: Marcel Apfelbaum , Yang Zhong , Peter Maydell , Stefano Stabellini , Eduardo Habkost , Rob Bradford , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Shannon Zhao , qemu-arm@nongnu.org, Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson On Thu, 22 Nov 2018 00:12:17 +0100 Samuel Ortiz wrote: > Hi Igor, > > On Wed, Nov 14, 2018 at 11:55:37AM +0100, Igor Mammedov wrote: > > On Mon, 5 Nov 2018 02:40:34 +0100 > > Samuel Ortiz wrote: > > > > > From: Yang Zhong > > > > > > The AML build routines for the PCI host bridge and the corresponding > > > DSDT addition are neither x86 nor PC machine type specific. > > > We can move them to the architecture agnostic hw/acpi folder, and by > > > carrying all the needed information through a new AcpiPciBus structure, > > > we can make them PC machine type independent. > > > > I'm don't know anything about PCI, but functional changes doesn't look > > correct to me. > > > > See more detailed comments below. > > > > Marcel, > > could you take a look on this patch (in particular main csr changes), pls? > > > > > > > > Signed-off-by: Yang Zhong > > > Signed-off-by: Rob Bradford > > > Signed-off-by: Samuel Ortiz > > > --- > > > include/hw/acpi/aml-build.h | 8 ++ > > > hw/acpi/aml-build.c | 157 ++++++++++++++++++++++++++++++++++++ > > > hw/i386/acpi-build.c | 115 ++------------------------ > > > 3 files changed, 173 insertions(+), 107 deletions(-) > > > > > > diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h > > > index fde2785b9a..1861e37ebf 100644 > > > --- a/include/hw/acpi/aml-build.h > > > +++ b/include/hw/acpi/aml-build.h > > > @@ -229,6 +229,12 @@ typedef struct AcpiMcfgInfo { > > > uint32_t mcfg_size; > > > } AcpiMcfgInfo; > > > > > > +typedef struct AcpiPciBus { > > > + PCIBus *pci_bus; > > > + Range *pci_hole; > > > + Range *pci_hole64; > > > +} AcpiPciBus; > > Again, this and all below is not aml-build material. > > Consider adding/using pci specific acpi file for it. > > > > Also even though pci AML in arm/virt is to a large degree a subset > > of x86 target and it would be much better to unify ARM part with x86, > > it probably will be to big/complex of a change if we take on it in > > one go. > > > > So not to derail you from the goal too much, we probably should > > generalize this a little bit less, limiting refactoring to x86 > > target for now. > So keeping it under i386 means it won't be accessible through hw/acpi/, > which means we won't be able to have a generic hw/acpi/reduced.c > implementation. From our perspective, this is the problem with keeping > things under i386 because we're not sure yet how much generic it is: It > still won't be shareable for a generic hardware-reduced ACPI > implementation which means we'll have to temporarily have yet another > hardware-reduced ACPI implementation under hw/i386 this time. > I guess this is what Michael meant by keeping some parts of the code > duplicated for now. > > I feel it'd be easier to move those APIs under a shareable location, to > make it easier for ARM to consume it even if it's not entirely generic yet. > But you guys are the maintainers and if you think we should restric the > generalization to x86 only for now, we can go for it. If code is generic (you can reuse it with arm/virt in the same series) then place it in hw/acpi otherwise if it's semi-generic put to hw/i386. If it would be a separate file it would be easier to move it to generic place when we are able to resuse it with arm/virt. > Cheers, > Samuel.