On Wed, Apr 04, 2012 at 09:42:32PM -0600, Alex Williamson wrote: > We've hit a kernel host panic, when issuing a 'system_reset' with an > 82576 nic assigned and a Windows guest. Host system is a PowerEdge R815. > > [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 32993 > [Hardware Error]: APEI generic hardware error status > [Hardware Error]: severity: 1, fatal > [Hardware Error]: section: 0, severity: 1, fatal > [Hardware Error]: flags: 0x01 > [Hardware Error]: primary > [Hardware Error]: section_type: PCIe error > [Hardware Error]: port_type: 0, PCIe end point > [Hardware Error]: version: 1.0 > [Hardware Error]: command: 0x0000, status: 0x0010 > [Hardware Error]: device_id: 0000:08:00.0 > [Hardware Error]: slot: 1 > [Hardware Error]: secondary_bus: 0x00 > [Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9 > [Hardware Error]: class_code: 000002 > [Hardware Error]: aer_status: 0x00100000, aer_mask: 0x00018000 > [Hardware Error]: Unsupported Request > [Hardware Error]: aer_layer=Transaction Layer, aer_agent=Requester ID > [Hardware Error]: aer_uncor_severity: 0x00067011 > [Hardware Error]: aer_tlp_header: 40001001 0020000f edbf800c 01000000 > [Hardware Error]: section: 1, severity: 1, fatal > [Hardware Error]: flags: 0x01 > [Hardware Error]: primary > [Hardware Error]: section_type: PCIe error > [Hardware Error]: port_type: 0, PCIe end point > [Hardware Error]: version: 1.0 > [Hardware Error]: command: 0x0000, status: 0x0010 > [Hardware Error]: device_id: 0000:08:00.0 > [Hardware Error]: slot: 1 > [Hardware Error]: secondary_bus: 0x00 > [Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9 > [Hardware Error]: class_code: 000002 > [Hardware Error]: aer_status: 0x00100000, aer_mask: 0x00018000 > [Hardware Error]: Unsupported Request > [Hardware Error]: aer_layer=Transaction Layer, aer_agent=Requester ID > [Hardware Error]: aer_uncor_severity: 0x00067011 > [Hardware Error]: aer_tlp_header: 40001001 0020000f edbf800c 01000000 > Kernel panic - not syncing: Fatal hardware error! > Pid: 0, comm: swapper Not tainted 2.6.32-242.el6.x86_64 #1 > Call Trace: > <NMI> [<ffffffff814f2fe5>] ? panic+0xa0/0x168 > [<ffffffff812f919c>] ? ghes_notify_nmi+0x17c/0x180 > [<ffffffff814f91d5>] ? notifier_call_chain+0x55/0x80 > [<ffffffff814f923a>] ? atomic_notifier_call_chain+0x1a/0x20 > [<ffffffff8109667e>] ? notify_die+0x2e/0x30 > [<ffffffff814f6e81>] ? do_nmi+0x1a1/0x2b0 > [<ffffffff814f6760>] ? nmi+0x20/0x30 > [<ffffffff8103762b>] ? native_safe_halt+0xb/0x10 > <<EOE>> [<ffffffff8101495d>] ? default_idle+0x4d/0xb0 > [<ffffffff81009e06>] ? cpu_idle+0xb6/0x110 > [<ffffffff814da63a>] ? rest_init+0x7a/0x80 > [<ffffffff81c1ff7b>] ? start_kernel+0x424/0x430 > [<ffffffff81c1f33a>] ? x86_64_start_reservations+0x125/0x129 > [<ffffffff81c1f438>] ? x86_64_start_kernel+0xfa/0x109 > > The root cause of the problem is that the 'reset_assigned_device()' code > first writes a 0 to the command register. Then, when qemu subsequently does > a kvm_deassign_irq() (called by assign_irq(), in the system_reset path), > the kernel ends up calling '__msix_mask_irq()', which performs a write to > the memory mapped msi vector space. Since, we've explicitly told the device > to disallow mmio access (via the 0 write to the command register), we end > up with the above 'Unsupported Request'. > > The fix here is to first disable MSI-X, before doing the reset. We also > disable MSI, leaving the device in INTx mode. In this way, the device is > a known state after reset, and we avoid touching msi memory mapped space > on any subsequent 'kvm_deassign_irq()'. > > Thanks to Michael S. Tsirkin for help in understanding what was going on > here and Jason Baron, the original debugger of this problem. > > Signed-off-by: Alex Williamson <alex.williamson@xxxxxxxxxx> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
