On Tue, Nov 02, 2010 at 02:01:08PM -0500, Ryan Harper wrote: > > > > > 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.
I imagine management would typically want to do this: 1. notify guest 2. wait a bit 3. remove device A twist is when guest disabled the device already. Then it would just want to remove the device. > -- > Ryan Harper > Software Engineer; Linux Technology Center > IBM Corp., Austin, Tx > ry...@us.ibm.com