On Wed, Oct 28, 2020 at 11:00:38AM +0000, Stefan Hajnoczi wrote: > On Tue, Oct 27, 2020 at 09:04:46AM -0400, Michael S. Tsirkin wrote: > > It's not a waste of time, it's just a lot of work > > within guests. > > Luckily it does no harm to set the NEEDS_RESET bit even if the guest > doesn't handle it. > > If the guest driver is unaware it may continue to submit requests to the > device for a while. The device emulation code stops accepting new > requests though. This means the device will become unresponsive until > reset, which is not ideal but okay in the case where the device was put > into an invalid state.
There is no actual rule that device must stop processing requests. Driver can only assume that is the case after it started the actual reset. > I agree that supporting NEEDS_RESET transparently inside guests is > difficult. The driver needs to reset and resume the device without > reporting errors to applications. In some cases drivers may not have > enough state in order to do that. It's also tricky to test all code > paths. I guess this is why no one has done it: drivers shouldn't enter > the NEEDS_RESET state anyway and handling it is complex. > > Stefan
