Re: Add support for ACPI Module Device ACPI0004?

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
> _at__at_ -653,7 +653,7 _at__at_ 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