Re: [Xen-devel] 3.18 xen-pcifront regression?

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Mar 24, 2015 at 11:14:29AM -0400, Michael D Labriola wrote:
> I'm having problems booting a 3.18 or newer domU w/ PCI devices passed 
> through.  It only seems to be the domU kernel that's upset (i.e., Behavior 
> is identical whether I'm running 3.19 or 3.13 dom0).  I'm running a 32bit 
> dom0 (3.13.11) w/ 64bit 4.4.0 hypervisor and 32bit domU.  I get the 
> following Oops when trying to boot my domU with a couple PCI cards passed 
> through:
> 
> BUG: unable to handle kernel paging request at 0030303e
> IP: [<c06ed0e6>] acpi_ns_validate_handle+0x12/0x1a
> *pdpt = 00000000019f1027 *pde = 0000000000000000 
> Oops: 0000 [#1] PREEMPT SMP 
> Modules linked in: xen_pcifront(+) pcspkr xen_blkfront loop
> CPU: 0 PID: 18 Comm: xenwatch Not tainted 3.17.0-test+ #6
> task: cb869950 ti: cb8ae000 task.ti: cb8ae000
> EIP: 0061:[<c06ed0e6>] EFLAGS: 00010246 CPU: 0
> EIP is at acpi_ns_validate_handle+0x12/0x1a
> EAX: 00000000 EBX: cb895dc0 ECX: 00000000 EDX: 0030303a
> ESI: c0a6bccd EDI: 00000000 EBP: 00000004 ESP: cb8afd00
>  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
> CR0: 8005003b CR2: 0030303e CR3: 0a68e000 CR4: 00040660
> Stack:
>  c06eda4d 00000000 c096a21d 00000000 00000000 00006462 00000000 c0c102c0
>  0030303a 00040004 0030303a cb8afd94 cb8afdec cb8afd60 c06b78e1 cb8afd60
>  00000061 00000246 c0407bc7 c0c102c0 00000000 cb8afda0 cb8afda8 cb8afdb0
> Call Trace:
>  [<c06eda4d>] ? acpi_evaluate_object+0x31/0x1fc

We should not be calling in any acpi code in PV domU guests.

WE actually disable it (acpi=0) to make sure we don't call it - as
there is no ACPI AML data at all in the guest.

CC-ing Bjorn.
>  [<c096a21d>] ? resume_kernel+0x5/0x7
>  [<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
>  [<c06975ce>] ? pci_bus_read_config_word+0x6e/0x80
>  [<c069a66d>] ? pci_scan_single_device+0x8d/0xb0
>  [<c069a6cc>] ? pci_scan_slot+0x3c/0xf0
>  [<c069b1bc>] ? pci_scan_child_bus+0x1c/0x90
>  [<c069b71a>] ? pci_scan_bus_parented+0x6a/0x90
>  [<d088d241>] ? pcifront_scan_root+0x91/0x130 [xen_pcifront]
>  [<d088e69f>] ? pcifront_backend_changed+0x4af/0x654 [xen_pcifront]
>  [<c070dd0f>] ? xenbus_gather+0x5f/0x90
>  [<c070dd0f>] ? xenbus_gather+0x5f/0x90
>  [<c070c393>] ? xenbus_read_driver_state+0x33/0x50
>  [<c070f375>] ? xenbus_otherend_changed+0x95/0xa0
>  [<c0710a5f>] ? backend_changed+0xf/0x20
>  [<c070d712>] ? xenwatch_thread+0x72/0x110
>  [<c0486140>] ? bit_waitqueue+0x50/0x50
>  [<c070d6a0>] ? join+0x70/0x70
>  [<c046e59b>] ? kthread+0xab/0xd0
>  [<c096a1c1>] ? ret_from_kernel_thread+0x21/0x30
>  [<c046e4f0>] ? flush_kthread_worker+0xa0/0xa0
> Code: 03 10 00 00 eb 0e 46 83 c2 04 4b 85 db 75 b9 c6 02 00 31 c0 5b 5e 5f 
> 5d c3 89 c2 8d 40 ff 83 f8 fd 76 06 a1 2c 32 c1 c0 c3 31 c0 <80> 7a 04 0f 
> 0f 44 c2 c3 83 ec 10 83 f8 1d 76 24 89 44 24 0c c7
> EIP: [<c06ed0e6>] acpi_ns_validate_handle+0x12/0x1a SS:ESP 0069:cb8afd00
> CR2: 000000000030303e
> ---[ end trace d4ddeb038cbcbdf7 ]---
> 
> 
> I've bisected down to the following commit in 3.18, which breaks my 
> system.
> 
> 6cd33649fa83d97ba7b66f1d871a360e867c5220 is the first bad commit
> commit 6cd33649fa83d97ba7b66f1d871a360e867c5220
> Author: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> Date:   Wed Aug 27 14:29:47 2014 -0600
> 
>     PCI: Add pci_configure_device() during enumeration
>  
>     Some platforms can tell the OS how to configure PCI devices, e.g., how 
> to
>     set cache line size, error reporting enables, etc.  ACPI defines _HPP 
> and
>     _HPX methods for this purpose.
>  
>     This configuration was previously done by some of the hotplug drivers 
> using
>     pci_configure_slot().  But not all hotplug drivers did this, and per 
> the
>     spec (ACPI rev 5.0, sec 6.2.7), we can also do it for "devices not
>     configured by the BIOS at system boot."
>  
>     Move this configuration into the PCI core by adding 
> pci_configure_device()
>     and calling it from pci_device_add(), so we do this for all devices as 
> we
>     enumerate them.
>  
>     This is based on pci_configure_slot(), which is used by hotplug 
> drivers.
>     I omitted:
>  
>       - pcie_bus_configure_settings() because it configures MPS and MRRS, 
> which
>         requires global knowledge of the fabric and must be done later, 
> and
>  
>       - configuration of subordinate devices; that will happen when we 
> call
>         pci_device_add() for those devices.
>  
>     Because pci_configure_slot() was only done by hotplug drivers, this 
> initial
>     version of pci_configure_device() only configures hot-added devices,
>     ignoring anything added during boot.
>  
>     Signed-off-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
>     Acked-by: Yinghai Lu <yinghai@xxxxxxxxxx>
> 
> :040000 040000 4fadbe1e5f8f18daa6be7bdb7c9c1d6def0a2615 
> 9aef037aa35ca156ac46553f7fc4c5b1b3980c19 M      drivers
> 
> 
> I've reverted that commit on top of 3.19, which feels incredibly wrong, 
> but does fix the problem on my system.  This is a little over my head, 
> though...  ;-)
> 
> Thoughts?
> 
> ---
> Michael D Labriola
> Electric Boat
> mlabriol@xxxxxxxx
> 401-848-8871 (desk)
> 401-848-8513 (lab)
> 401-316-9844 (cell)
> 
> 
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel