Re: [Qemu-devel] Change the condition that permits to use device_del QOM-path on device? was (spapr: Gracefully fail CPU thread unplug)

[Igor Mammedov]

On Thu, 18 Aug 2016 15:50:45 +0530
Bharata B Rao <address@hidden> 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 <address@hidden>
> > > Signed-off-by: Bharata B Rao <address@hidden>  
> > 
> > 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.
>