Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal

[Ryan Harper <ryanh@us.ibm.com>]

> > > > I like the idea of disconnect; if part of the device_del method was to
> > > > invoke a disconnect method, we could implement that for block, net, etc;
> > > > 
> > > > I'd think we'd want to send the notification, then disconnect.
> > > > Struggling with whether it's worth having some reasonable timeout
> > > > between notification and disconnect.  
> > > 
> > > The problem with this is that it has no analog in real world.
> > > In real world, you can send some notifications to the guest, and you can
> > > remove the card.  Tying them together is what created the problem in the
> > > first place.
> > > 
> > > Timeouts can be implemented by management, maybe with a nice dialog
> > > being shown to the user.
> > 
> > Very true.  I'm fine with forcing a disconnect during the removal path
> > prior to notification.  Do we want a new disconnect method at the device
> > level (pci)? or just use the existing removal callback and call that
> > during the initial hotremov event?
> 
> Not sure what you mean by that, but I don't see a device doing anything
> differently wrt surprise or ordered removal. So probably the existing
> callback should do. I don't think we need to talk about disconnect:
> since we decided we are emulating device removal, let's call it
> just that.

Because current the "removal" process depends on the guest actually
responding.  What I'm suggesting is that, in Marcus's term, and what
drive_unplug() implements, is to disconnect the host block device from
the guest device to prevent any further access to it in the case the
guest doesn't respond to the removal request made via ACPI.

Very specifically, what we're suggesting instead of the drive_unplug()
command so to complete the device removal operation without waiting for
the guest to respond; that's what's going to happen if we invoke the
response callback; it will appear as if the guest responded whether it
did or not.

What I was suggesting above was to instead of calling the callback for
handing the guest response was to add a device function called
disconnect which would remove any association of host resources from
guest resources before we notified the guest.  Thinking about it again
I'm not sure this is useful, but if we're going to remove the device
without the guests knowledge, I'm not sure how useful sending the
removal requests via ACPI is in the first place.

My feeling is that I'd like to have explicit control over the disconnect
from host resources separate from the device removal *if* we're going to
retain the guest notification.  If we don't care to notify the guest,
then we can just do device removal without notifying the guest
and be done with it.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com