3.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
commit 8647ca9ad5a0065ad53a2ad7e39163592b6ed35e upstream.
Booting a v3.18 or newer Xen domU kernel with PCI devices passed through
results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0
hypervisor and 32-bit domU):
BUG: unable to handle kernel paging request at 0030303e
IP: [<c06ed0e6>] acpi_ns_validate_handle+0x12/0x1a
Call Trace:
[<c06eda4d>] ? acpi_evaluate_object+0x31/0x1fc
[<c06b78e1>] ? pci_get_hp_params+0x111/0x4e0
[<c0407bc7>] ? xen_force_evtchn_callback+0x17/0x30
[<c04085fb>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<c0699d34>] ? pci_device_add+0x24/0x450
Don't look for ACPI configuration information if ACPI has been disabled.
I don't think this is the best fix, because we can boot plain Linux (no
Xen) with "acpi=off", and we don't need this check in pci_get_hp_params().
There should be a better fix that would make Xen domU work the same way.
The domU kernel has ACPI support but it has no AML. There should be a way
to initialize the ACPI data structures so things fail gracefully rather
than oopsing. This is an interim fix to address the regression.
Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301
Reported-by: Michael D Labriola <mlabriol@xxxxxxxx>
Tested-by: Michael D Labriola <mlabriol@xxxxxxxx>
Signed-off-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/pci/pci-acpi.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -248,6 +248,9 @@ int pci_get_hp_params(struct pci_dev *de
acpi_handle handle, phandle;
struct pci_bus *pbus;
+ if (acpi_pci_disabled)
+ return -ENODEV;
+
handle = NULL;
for (pbus = dev->bus; pbus; pbus = pbus->parent) {
handle = acpi_pci_get_bridge_handle(pbus);
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html