Bug 1215953
| Summary: | [virtio-win][viostor]virtio-blk-pci should support surprise-removal during device in use | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | lijin <lijin> | ||||
| Component: | virtio-win | Assignee: | Vadim Rozenfeld <vrozenfe> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.1 | CC: | bcao, jinzhao, juli, rbalakri, virt-maint | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-06-28 23:13:43 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
lijin
2015-04-28 08:29:21 UTC
(In reply to lijin from comment #0) > Created attachment 1019569 [details] > virtio-blk-pci hot-unplug > > Description of problem: > QE hit similar issue(unplug failed) when do hot-unplug virtio-win device in > use in windows guest. > > According to following page,linux guest can do the surprised unplug > correctly; > https://mojo.redhat.com/docs/DOC-187573 Windows and Linux can be very different in regard to how they handle PnP requests. > > And as Gal said in https://bugzilla.redhat.com/show_bug.cgi?id=957328#c20 > "The driver can tell Windows that it support a surprise-removal" > Well, this is a complicity incorrect statement. Some WDM-style driver can say that it's OK for the underlying device to be removed surprisingly, and these drivers even can implement some optimised paths for handling surprise removal sequence. If it is the case, than Windows will depress a pop-up dialog saying that a device has been removed surprisingly. Surprise removal is nothing else then just brutal force pulling a device out of it's slot or socket and a device driver cannot do anything about this situation, at leas it cannot agree or disagree with that situation. What MST said in https://bugzilla.redhat.com/show_bug.cgi?id=957328#c18 is that QEMU doesn't support this brutal force device removal, but handles "device_del" properly, by sending an appropriate request to the guest to make a proper decision to handle or to reject this request. Handling or failing a PnP request is a different and a very complicated issue. But technically, any WDM driver in a device stack can fail a PnP request based on the bunch of different facts and conditions (for example if the underlying device is idle or busy. Technically, it is exactly what happens in your case, when FS driver just rejects the PnP request for the storage device removal). Closing this bug as wontfix. BTW, we closed a very similar bug some time ago for absolutely the same reason as I mentioned above. Best regards, Vadim. > So file this bug to track virtio-blk-pci > > Version-Release number of selected component (if applicable): > > > How reproducible: > 100% > > Steps to Reproduce: > 1.boot a win7-32 guest with one virtio-blk-pci data disk; > 2.copy a big file from smb server to data disk > 3.hotunplug the virtio-blk-pci during step2 > > Actual results: > guest prompts a window as "the device is currently in use.xxxx"(please check > the attachment). > And in device manager the virtio-blk Driver still exist. > > Expected results: > virtio-blk-pci can be surprised removed without any error > > Additional info: *** Bug 1375901 has been marked as a duplicate of this bug. *** *** Bug 1002384 has been marked as a duplicate of this bug. *** |