> From: John Baldwin [mailto:jhb_at_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[] = { "PNP0C01", "PNP0C02", NULL }; > > + static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", 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 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 can't see the length of the MMIO range in the dumped asl code, it does have 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? -- DexuanReceived on Thu Apr 20 2017 - 00:29:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC