pcicfg: Fix direct calls of pci_cfg{read,write} on system w/o PCI host bridge.

[sepherosa_gmail.com]

Summary

Reported-by: dexuan@

[decui_microsoft.com]

We need this patch to make PCIe pass-through work for Hyper-V UEFI VM (Generation 2 VM).

Hyper-V UEFI VM has no legacy pcib0, so pci_cfgregopen() doesn't have a chance to be called to initialize 'pcicfg_mtx.
Some unusual drivers (like hptiop/hptmv/hptnr/hptrr/hpt27xx), which don't conform to Newbus, call pcireg_cfgread() directly e.g. in hpt_match() -> get_controller_count() -> ... -> pcireg_cfgread() -> mtx_lock_spin(&pcicfg_mtx) hangs!!! The patch fixes the issue.

[jhb]

I'd kind of prefer we fix the drivers, though I think this patch is fine for now. I have an open item to refactor even the ACPI code to not use pci_cfgreg* directly but instead punt that up to the parent of acpi0 (nexus0) to support arm64 (and to support systems with multiple domains).

[sepherosa_gmail.com]

In D10564#219024, @jhb wrote:

I'd kind of prefer we fix the drivers, though I think this patch is fine for now. I have an open item to refactor even the ACPI code to not use pci_cfgreg* directly but instead punt that up to the parent of acpi0 (nexus0) to support arm64 (and to support systems with multiple domains).

Well, all of the problematic drivers are blob ones. I am not even quite sure about why they want to read config space directly, instead of using pci_{read,write}_config. And with in the increasing number of vendor maintained/imported drivers, it's becoming difficult to fix drivers or audit the drivers before importing them. So that's why I prefer to fix it in the pci.

If no objection comes, I will commit it tomorrow.