On Thu, May 18, 2017 at 04:10:28PM +0100, Ard Biesheuvel wrote: [...] > >> Re _DSM: I think it makes sense to honour it, because it puts the > >> allocation under the control of the firmware, which completely removes > >> the burden of having to reason about a policy in the kernel. That > >> leaves the question which will be the default, but that is of minor > >> importance IMO. > > > > I agree; we should try to follow the spec unless we have a good reason > > not to, which argues for honoring the _DSM, so I think it's worth a > > try. Booting with "pci=realloc" could override the _DSM and taint the > > kernel (because we don't know the effect of reassigning something the > > firmware told us not to touch). > > > > I'd like to hear Lorenzo's view on this first, but I can certainly > respin my _DSM patch to take pci=realloc into account, and move the > handling to generic code as well. I agree with both of you on _DSM implementation and interpretation. Now, if we use it correctly (ie by the FW standard) on ARM64 systems we are going to trigger regressions, that's certain (ie we can then boot with pci=realloc - still, we are breaking systems), that's the reason why for patch(2) I'd like to create a branch and send a CFT for ARM64 ACPI testing before queuing it (either I can set-up a testing branch or we ask Bjorn to do it - as you guys prefer - as long as we have a branch for people to test patch(2) on ARM64 ACPI systems). You still need to assign resources that could not be claimed though so patch(2) still needs updating: PCI FW spec 3.1 - 4.6.5 "...However, the operating system is free to configure the devices in this hierarchy that have not been configured by the firmware." Which in kernel-speak it means that you have to assign resources that could not be claimed. Thanks ! Lorenzo
