aboutsummaryrefslogtreecommitdiff
path: root/include/disas
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2019-08-13 15:59:18 +1000
committerDavid Gibson <david@gibson.dropbear.id.au>2019-08-13 15:59:21 +1000
commit25c9780d38d4494f8610371d883865cf40b35dd6 (patch)
tree475d6d17974b49236852fbbe4cb498603a8fcc38 /include/disas
parent5e7bcdcfe69ce0fad66012b2cfb2035003c37eef (diff)
downloadqemu-25c9780d38d4494f8610371d883865cf40b35dd6.zip
qemu-25c9780d38d4494f8610371d883865cf40b35dd6.tar.gz
qemu-25c9780d38d4494f8610371d883865cf40b35dd6.tar.bz2
spapr: Reset CAS & IRQ subsystem after devices
This fixes a nasty regression in qemu-4.1 for the 'pseries' machine, caused by the new "dual" interrupt controller model. Specifically, qemu can crash when used with KVM if a 'system_reset' is requested while there's active I/O in the guest. The problem is that in spapr_machine_reset() we: 1. Reset the CAS vector state spapr_ovec_cleanup(spapr->ov5_cas); 2. Reset all devices qemu_devices_reset() 3. Reset the irq subsystem spapr_irq_reset(); However (1) implicitly changes the interrupt delivery mode, because whether we're using XICS or XIVE depends on the CAS state. We don't properly initialize the new irq mode until (3) though - in particular setting up the KVM devices. During (2), we can temporarily drop the BQL allowing some irqs to be delivered which will go to an irq system that's not properly set up. Specifically, if the previous guest was in (KVM) XIVE mode, the CAS reset will put us back in XICS mode. kvm_kernel_irqchip() still returns true, because XIVE was using KVM, however XICs doesn't have its KVM components intialized and kernel_xics_fd == -1. When the irq is delivered it goes via ics_kvm_set_irq() which assert()s that kernel_xics_fd != -1. This change addresses the problem by delaying the CAS reset until after the devices reset. The device reset should quiesce all the devices so we won't get irqs delivered while we mess around with the IRQ. The CAS reset and irq re-initialize should also now be under the same BQL critical section so nothing else should be able to interrupt it either. We also move the spapr_irq_msi_reset() used in one of the legacy irq modes, since it logically makes sense at the same point as the spapr_irq_reset() (it's essentially an equivalent operation for older machine types). Since we don't need to switch between different interrupt controllers for those old machine types it shouldn't actually be broken in those cases though. Cc: Cédric Le Goater <clg@kaod.org> Fixes: b2e22477 "spapr: add a 'reset' method to the sPAPR IRQ backend" Fixes: 13db0cd9 "spapr: introduce a new sPAPR IRQ backend supporting XIVE and XICS" Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'include/disas')
0 files changed, 0 insertions, 0 deletions