ppc/xics: fix ICP reset path
Recent cleanup in commit a028dd42 dropped the ICPStateClass::reset handler. It is now up to child ICP classes to call the DeviceClass::reset handler of the parent class, thanks to device_class_set_parent_reset(). This is a better object programming pattern, but unfortunately it causes QEMU to crash during CPU hotplug: (qemu) device_add host-spapr-cpu-core,id=core1,core-id=1 Segmentation fault (core dumped) When the hotplug path tries to reset the ICP device, we end up calling: static void icp_kvm_reset(DeviceState *dev) { ICPStateClass *icpc = ICP_GET_CLASS(dev); icpc->parent_reset(dev); but icpc->parent_reset is NULL... This happens because icp_kvm_class_init() calls: device_class_set_parent_reset(dc, icp_kvm_reset, &icpc->parent_reset); but dc->reset, ie, DeviceClass::reset for the TYPE_ICP type, is itself NULL. This patch hence sets DeviceClass::reset for the TYPE_ICP type to point to icp_reset(). It then registers a reset handler that calls DeviceClass::reset. If the ICP subtype has configured its own reset handler with device_class_set_parent_reset(), this ensures it will be called first and it can then call ICPStateClass::parent_reset safely. This fixes the reset path for the TYPE_KVM_ICP type, which is the only subtype that defines its own reset function. Reported-by: NSatheesh Rajendran <sathnaga@linux.vnet.ibm.com> Suggested-by: NDavid Gibson <david@gibson.dropbear.id.au> Fixes: a028dd42Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Showing
想要评论请 注册 或 登录