| commit | 2c5534776b375bbaff3896420e41cb981d40e2bc | |
| author | David Gibson <david@gibson.dropbear.id.au> | |
| Wed, 7 Jun 2017 07:06:44 +0000 (7 17:06 +1000) | ||
| committer | David Gibson <david@gibson.dropbear.id.au> | |
| Thu, 8 Jun 2017 04:38:18 +0000 (8 14:38 +1000) | ||
| tree | 2c86af6e415e4b6a6b927826a2a151da5bfce2f8 | treesnapshot (tar.gz zip) |
| parent | 8a9e0e7b890b2598da94646bf6a7272f3d3924de | commitdiff |
pseries: Correct panic behaviour for pseries machine type
The pseries machine type doesn't usually use the 'pvpanic' device as such,
because it has a firmware/hypervisor facility with roughly the same
purpose. The 'ibm,os-term' RTAS call notifies the hypervisor that the
guest has crashed.
Our implementation of this call was sending a GUEST_PANICKED qmp event;
however, it was not doing the other usual panic actions, making its
behaviour different from pvpanic for no good reason.
To correct this, we should call qemu_system_guest_panicked() rather than
directly sending the panic event.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Thomas Huth <thuth@redhat.com>
The pseries machine type doesn't usually use the 'pvpanic' device as such,
because it has a firmware/hypervisor facility with roughly the same
purpose. The 'ibm,os-term' RTAS call notifies the hypervisor that the
guest has crashed.
Our implementation of this call was sending a GUEST_PANICKED qmp event;
however, it was not doing the other usual panic actions, making its
behaviour different from pvpanic for no good reason.
To correct this, we should call qemu_system_guest_panicked() rather than
directly sending the panic event.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Thomas Huth <thuth@redhat.com>
| hw/ppc/spapr_rtas.c | diffblobblamehistory |