acpi bus: store children domain in ivar

[kib]

Summary

This should allow to properly report domain for DMARs, and also make some more allocations (like sc) to follow affinity.

sysctl dev.: dynamically calculate device' domain

dev/acpica: rename acpi_get_domain() to acpi_get_domain_method()

 acpica: add domain ivar    
 Specialize acpi bus_get_domain method to read ivar, and fall back to
 _PXM if ivar is not set.  If _PXM was used, its result is cached in
 ivar.

 dmar: set acpi ivar domain on identify()

[jhb]

I would suggest parsing _PXM up front when we enumerate devices in the namespace and just set the ivar then.

sys/dev/acpica/acpi_pci.c

111 ↗

(On Diff #145478)

Hmm, so you are trying to avoid changing this driver to also cache _PXM I guess.

sys/kern/subr_bus.c

269 ↗

(On Diff #145478)

I don't understand the need for the changes in this file. bus_get_domain() should still work the first time it is called and the value will never change?

[kib]

sys/dev/acpica/acpi_pci.c

111 ↗

(On Diff #145478)

Where would I cache the _PXM value? It is arbitrary pci bus child that ends up calling this method, so I cannot know where to save my bit of data.

sys/kern/subr_bus.c

269 ↗

(On Diff #145478)

I want to be able to set the domain ivar later then identify. For that, bus_get_domain() might fail during the sysctl_init() but work after e.g. attach.

These changes are separate, I can omit them for now if objected.

[kib]

Call _PXM for acpi children at enumeration time.

[jhb]

sys/dev/acpica/acpi.c

1309

I would maybe now move this function to acpi_pci.c and call it acpi_pci_get_domain (it would be static then as well) and then the new function added below can just be acpi_get_domain_method?

sys/kern/subr_bus.c

269 ↗

(On Diff #145478)

Hmm, the current devices here set it during identify, so I guess you anticipate needing this for a future driver? It does seem a bit odd for a child device to set this during attach since it's a bus method, that is, the parent bus is responsible for determining the domain and should in theory know it before a child device attaches?

[kib]

sys/kern/subr_bus.c

269 ↗

(On Diff #145478)

I do not quite understand newbus organization. For me, it is strange that the bus needs to know what is the device' affinity. Esp. for pseudo-bus like ACPI, where devices come from enumerating device namespace, but also from random ACPI tables like DMAR or HPET.

Another example of the ACPI child which uses special way to define affinity is NVDIMM, where NFIT table provides the domain number for given physical address range backed by NVDIMM (I believe it is done this way to support also interleave configs).

We definitely do not want to teach the acpi0 bus to parse all that tables. Either we introduce the intermediate bus to report affinity, or we need to allow the children to do it.

[kib]

Use acpi_pci_get_domain() private method.
Rename acpi_parse_pxm() to acpi_pxm_parse() for consistency with other external functions.

[kib]

Ping?

[jhb]

I would defer the subr_bus.c change until we have a use case that needs it.

sys/kern/subr_bus.c

269 ↗

(On Diff #145478)

Normally it would be the responsibility of the device_identify() routine that adds the new child device to initialize ivars for a device (e.g. set the ACPI handle if there is one). device_identify() is kind of a special method that should initialize a device_t in all the ways that the bus would initialize devices the bus knows how to enumerate, and specifically setting ivars. So that means that various ACPI device drivers that enumerate devices via other ACPI tables are responsible for initializing the ivars for any devices they add.

[jhb]

All of the ACPI changes look good to me though