On Thu, 18 Aug 2016 15:50:45 +0530 Bharata B Rao <[email protected]> wrote:
> On Thu, Aug 18, 2016 at 10:57:04AM +1000, David Gibson wrote: > > On Wed, Aug 17, 2016 at 07:31:38PM +0530, Bharata B Rao wrote: > > > sPAPR supports only Core level CPU plug and unplug, but nothing > > > prevents user from issuing a device_del on the underlying thread > > > device by using its qom path directly. This hits g_assert(hotplug_ctrl) > > > in qdev_unplug(). > > > > > > Gracefully reject such unplug requests from ->unplug() handler > > > > > > Reported-by: Shivaprasad G Bhat <[email protected]> > > > Signed-off-by: Bharata B Rao <[email protected]> > > > > Why isn't there a graceful failure if we return NULL from the > > hotplug_handler()? Doesn't that indicate a bug in the generic code? > > Couldn't the same error be triggered by attempting to unplug some > > other random device - say the RTC on x86, or the NVRAM on POWER? > > True, realized that this error can be triggered for other devices as well > like dr-connector or icp devices. So it definitely doesn't make sense > to explicitly return a non-NULL hotplug_handler for all of these > and then fail the unplug gracefully from ->unplug() like I am doing here > for CPU thread devices. > > Hence, this particular fix isn't needed right now. May be we can gracefully > error out for all such cases from qdev_unplug(). device_del by QOM path was discussed here: https://patchwork.ozlabs.org/patch/516781/ but it only takes Device::hotpluggable into account, perhaps we should add something like DeviceClass::cannot_delete_device_del in addition to above? > > Regards, > Bharata. >
