From owner-freebsd-current@freebsd.org Fri Apr 28 09:36:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4C60D53AA8 for ; Fri, 28 Apr 2017 09:36:34 +0000 (UTC) (envelope-from decui@microsoft.com) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0101.outbound.protection.outlook.com [104.47.126.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CA90ACF; Fri, 28 Apr 2017 09:36:33 +0000 (UTC) (envelope-from decui@microsoft.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NGwrWpdQAnMoe1f+4C1Sstd7McOSBRWulgJoalfXSy8=; b=i40Ge0dVC6c3/DgJedjs2m+TOwkv1bcgx6zYdLfBNCnhssHWMzAr6CTIzozZZ9aXHAFaqvidkUbEZc0W4XCceVe66s5S3+5rQ1OR6BpaBVV8IWgOedszZG3V2uiEs7yYSi/rpPMXVlGnpLLWm9/P0axtdNUvGpBnRiU/7CJR/pY= Received: from HK2P15301MB0003.APCP153.PROD.OUTLOOK.COM (10.170.151.145) by HK2P15301MB0003.APCP153.PROD.OUTLOOK.COM (10.170.151.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.0; Fri, 28 Apr 2017 09:36:26 +0000 Received: from HK2P15301MB0003.APCP153.PROD.OUTLOOK.COM ([10.170.151.145]) by HK2P15301MB0003.APCP153.PROD.OUTLOOK.COM ([10.170.151.145]) with mapi id 15.01.1075.003; Fri, 28 Apr 2017 09:36:26 +0000 From: Dexuan Cui To: John Baldwin , Sepherosa Ziehau CC: "freebsd-current@freebsd.org" , Jung-uk Kim , Yanmin Qiao Subject: RE: Add support for ACPI Module Device ACPI0004? Thread-Topic: Add support for ACPI Module Device ACPI0004? Thread-Index: AQHSvqgiDro7P4OHStiOHYshQNXMIaHYlRrw Date: Fri, 28 Apr 2017 09:36:25 +0000 Message-ID: References: <5144516.9adee9646c@ralph.baldwin.cx> <3727893.2519smPuKm@ralph.baldwin.cx> In-Reply-To: <3727893.2519smPuKm@ralph.baldwin.cx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=decui@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-04-28T17:36:23.1412602+08:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: spf=none (sender IP is ) smtp.mailfrom=decui@microsoft.com; x-originating-ip: [167.220.255.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK2P15301MB0003; 7:uqOm7BMUONxJahqvgsfICs0Hj5uwD8mAs6/RB7YWOhydWMPTAd1kl/rWXXfmeB98qWJHJnGvs0GN2leHuZjQjFu5cXPUEFM/82xzRWsJrPvxQZljy5SCHe7JS23xjJmhImKfYm2NsvY1SUjUnJZn0S5u78Co/bnF3eaJ8ZXYlehNU2eTmmDf9mxtyT4loNGzOoSJDkRG5sao+9gVBU+OWCxD9d2jDzEuETBGb7nJCUnA/p4EVNeFijagylMhA5IWqj3aQwJvD8q4LWv4UXABmyzUjLWI3s8NAoI16Azq9buE9fQsvDOcJ0byl/hXwyox3by7smXytevhVza5uT/zOLe6jasZ+XNQvpAcvJ/F8BM= x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: 1b19221b-5ea9-4c9f-9d22-08d48e1a0a68 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:HK2P15301MB0003; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:HK2P15301MB0003; BCL:0; PCL:0; RULEID:; SRVR:HK2P15301MB0003; x-forefront-prvs: 029174C036 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39450400003)(39860400002)(39410400002)(39840400002)(51914003)(24454002)(377454003)(66066001)(10090500001)(107886003)(53546009)(5890100001)(55016002)(38730400002)(189998001)(229853002)(5005710100001)(6306002)(2906002)(3846002)(102836003)(305945005)(33656002)(2900100001)(10290500003)(74316002)(6116002)(345774005)(25786009)(86612001)(86362001)(6246003)(7736002)(54906002)(54356999)(6436002)(7696004)(77096006)(575784001)(39060400002)(8990500004)(50986999)(76176999)(6506006)(3280700002)(3660700001)(5660300001)(8936002)(2950100002)(8676002)(81166006)(53936002)(93886004)(4326008)(9686003)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:HK2P15301MB0003; H:HK2P15301MB0003.APCP153.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2017 09:36:25.5319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2P15301MB0003 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 09:36:35 -0000 > From: John Baldwin > Sent: Thursday, April 27, 2017 00:14 > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote: > > On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin wrote: > > > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote: > > >> > From: John Baldwin [mailto:jhb@freebsd.org] > > >> > Sent: Thursday, April 20, 2017 02:34 > > >> > > Can we add the support of "ACPI0004" with the below one-line > change? > > >> > > > > >> > > acpi_sysres_probe(device_t dev) > > >> > > { > > >> > > - static char *sysres_ids[] =3D { "PNP0C01", "PNP0C02", NULL = }; > > >> > > + static char *sysres_ids[] =3D { "PNP0C01", "PNP0C02", "ACPI= 0004", > NULL }; > > >> > > > > >> > Hmm, so the role of C01 and C02 is to reserve system resources, > though we > > >> > in turn allow any child of acpi0 to suballocate those ranges (sinc= e > historically > > >> > c01 and c02 tend to allocate I/O ranges that are then used by thin= gs > like the > > >> > EC, PS/2 keyboard controller, etc.). From my reading of ACPI0004 = in > the ACPI > > >> > 6.1 spec it's not quite clear that ACPI0004 is like that? In part= icular, it > > >> > seems that 004 should only allow direct children to suballocate? = This > > >> > change might work, but it will allow more devices to allocate the > ranges in > > >> > _CRS than otherwise. > > >> > > > >> > Do you have an acpidump from a guest system that contains an > ACPI0004 > > >> > node that you can share? > > >> > > > >> > John Baldwin > > >> > > >> Hi John, > > >> Thanks for the help! > > >> > > >> Please see the attached file, which is got by > > >> "acpidump -dt | gzip -c9 > acpidump.dt.gz" > > >> > > >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of > > >> "VMBus" (VMBS). > > >> It looks the _CRS of ACPI0004 is dynamically generated. Though we ca= n't > > >> see the length of the MMIO range in the dumped asl code, it does hav= e > > >> a 512MB MMIO range [0xFE0000000, 0xFFFFFFFFF]. > > >> > > >> It looks FreeBSD can't detect ACPI0004 automatically. > > >> With the above one-line change, I can first find the child device > > >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get > > >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range. > > >> > > >> If you think we shouldn't touch acpi_sysresource0 here, I guess > > >> we can add a new small driver for ACPI0004, just like we added VMBus > > >> driver as a child device of acpi0? > > > > > > Hmmm, so looking at this, the "right" thing is probably to have a dev= ice > > > driver for the ACPI0004 device that parses its _CRS and then allows i= ts > > > child devices to sub-allocate resources from the ranges in _CRS. How= ever, > > > this would mean make VMBus be a child of the ACPI0004 device. > Suppose > > > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' > device > > > would need to create a child device for all of its child devices. Ri= ght > > > now acpi0 also creates devices for them which is somewhat messy (acpi= 0 > > > creates child devices anywhere in its namespace that have a valid _HI= D). > > > You can find those duplicates and remove them during acpi_module0's > attach > > > routine before creating its own child device_t devices. (We associat= e > > > a device_t with each Handle when creating device_t's for ACPI handles > > > which is how you can find the old device that is a direct child of ac= pi0 > > > so that it can be removed). > > > > The remove/reassociate vmbus part seems kinda "messy" to me. I'd just > > hook up a new acpi0004 driver, and let vmbus parse the _CRS like what > > we did to the hyper-v's pcib0. >=20 > The acpi_pci driver used to do the remove/reassociate part. What acpi0 > should probably be doing is only creating device_t nodes for immediate > children. This would require an ACPI-aware isa0 for LPC devices below > the ISA bus in the ACPI namespace. We haven't done that in part because > BIOS vendors are not always consistent in placing LPC devices under an > ISA bus. However, you otherwise have no good way to find your parent > ACPI0004 device. You could perhaps find your ACPI handle, ask for its > parent handle, then ask for the device_t of that handle to find the > ACPI0004 device, but then you'd need to have all your bus_alloc_resource > calls go to that device, not your "real" parent of acpi0, which means > you can't use any of the standard bus_alloc_resource() methods like > bus_alloc_resource_any() but would have to manually use > BUS_ALLOC_RESOURCE > with the ACPI0004 device as the explicit first argument. It is primarily > the ability to let ACPI0004's driver transparently intercept all the > resource allocation so it can manage that is the reason for "VMBus" > to be a child of ACPI0004 rather than its sibling. >=20 > -- > John Baldwin Hi John, Thank you for the detailed analysis, but IMHO this seems too complex? :-) Can we just add a small driver for ACPI0004 like this: https://reviews.freebsd.org/D10531 This way, we only need to make a small change in VMBus driver reusing the current code: https://reviews.freebsd.org/D10532 Looking forward to your comment! Thanks, -- Dexuan