From owner-freebsd-current@freebsd.org Wed Apr 19 18:44:27 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 11BF3D4589A for ; Wed, 19 Apr 2017 18:44:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E30F3A18; Wed, 19 Apr 2017 18:44:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id A142910A7B9; Wed, 19 Apr 2017 14:44:18 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Dexuan Cui , Jung-uk Kim , Yanmin Qiao Subject: Re: Add support for ACPI Module Device ACPI0004? Date: Wed, 19 Apr 2017 11:34:15 -0700 Message-ID: <3484633.CMRgrtiqef@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 19 Apr 2017 14:44:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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: Wed, 19 Apr 2017 18:44:27 -0000 On Wednesday, April 19, 2017 12:26:51 PM Dexuan Cui wrote: > The ACPI firmware of Hyper-V UEFI VM has a Module Device whose Hardware > ID is "ACPI0004". The module device has a _CRS object defining some MMIO > ranges, which are needed when physical PCIe devices are passed through > to the VM. > > Currently it looks FreeBSD doesn't make use of the ACPI module device and > hence the _CRS object can't be easily retrieved by Hyper-V VMBus driver. > > Can we add the support of "ACPI0004" with the below one-line change? > > Looking forward to your suggestion! > > --- a/sys/dev/acpica/acpi_resource.c > +++ b/sys/dev/acpica/acpi_resource.c > @@ -653,7 +653,7 @@ MODULE_DEPEND(acpi_sysresource, acpi, 1, 1, 1); > static int > acpi_sysres_probe(device_t dev) > { > - static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL }; > + static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL }; > > if (acpi_disabled("sysresource") || > ACPI_ID_PROBE(device_get_parent(dev), dev, sysres_ids) == 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 (since historically c01 and c02 tend to allocate I/O ranges that are then used by things 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 particular, 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