| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I'm trying to pass-through Broadcom BCM5720 NIC (Dell device 1f5b) on a
Dell R720 server. Everything works fine when the target VM has only one
CPU, but SMP guests reboot when the NIC driver accesses PCI config space
with hv_pcifront_read_config()/hv_pcifront_write_config(). The reboot
appears to be induced by the hypervisor and no crash is observed. Windows
event logs are not helpful at all ('Virtual machine ... has quit
unexpectedly'). The particular access point is always different and
putting debug between them (printk/mdelay/...) moves the issue further
away. The server model affects the issue as well: on Dell R420 I'm able to
pass-through BCM5720 NIC to SMP guests without issues.
While I'm obviously failing to reveal the essence of the issue I was able
to come up with a (possible) solution: if explicit barriers are added to
hv_pcifront_read_config()/hv_pcifront_write_config() the issue goes away.
The essential minimum is rmb() at the end on _hv_pcifront_read_config() and
wmb() at the end of _hv_pcifront_write_config() but I'm not confident it
will be sufficient for all hardware. I suggest the following barriers:
1) wmb()/mb() between choosing the function and writing to its space.
2) mb() before releasing the spinlock in both _hv_pcifront_read_config()/
_hv_pcifront_write_config() to ensure that consecutive reads/writes to
the space won't get re-ordered as drivers may count on that.
Config space access is not supposed to be performance-critical so these
explicit barriers should not cause any slowdown.
[bhelgaas: use Linux "barriers" terminology]
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jake Oshins <jakeo@microsoft.com>
|
|
Kernel hang is observed when pci-hyperv module is release with device
drivers still attached. E.g., when I do 'rmmod pci_hyperv' with BCM5720
device pass-through-ed (tg3 module) I see the following:
NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [rmmod:2104]
...
Call Trace:
[<ffffffffa0641487>] tg3_read_mem+0x87/0x100 [tg3]
[<ffffffffa063f000>] ? 0xffffffffa063f000
[<ffffffffa0644375>] tg3_poll_fw+0x85/0x150 [tg3]
[<ffffffffa0649877>] tg3_chip_reset+0x357/0x8c0 [tg3]
[<ffffffffa064ca8b>] tg3_halt+0x3b/0x190 [tg3]
[<ffffffffa0657611>] tg3_stop+0x171/0x230 [tg3]
...
[<ffffffffa064c550>] tg3_remove_one+0x90/0x140 [tg3]
[<ffffffff813bee59>] pci_device_remove+0x39/0xc0
[<ffffffff814a3201>] __device_release_driver+0xa1/0x160
[<ffffffff814a32e3>] device_release_driver+0x23/0x30
[<ffffffff813b794a>] pci_stop_bus_device+0x8a/0xa0
[<ffffffff813b7ab6>] pci_stop_root_bus+0x36/0x60
[<ffffffffa02c3f38>] hv_pci_remove+0x238/0x260 [pci_hyperv]
The problem seems to be that we report local resources release before
stopping the bus and removing devices from it and device drivers may try to
perform some operations with these resources on shutdown. Move resources
release report after we do pci_stop_root_bus().
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jake Oshins <jakeo@microsoft.com>
|
|
Add a new driver which exposes a root PCI bus whenever a PCI Express device
is passed through to a guest VM under Hyper-V. The device can be single-
or multi-function. The interrupts for the devices are managed by an IRQ
domain, implemented within the driver.
[bhelgaas: fold in race condition fix (http://lkml.kernel.org/r/1456340196-13717-1-git-send-email-jakeo@microsoft.com)]
Signed-off-by: Jake Oshins <jakeo@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
