From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R72lO-00050l-1g for qemu-devel@nongnu.org; Fri, 23 Sep 2011 06:13:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R72lN-0000sb-4F for qemu-devel@nongnu.org; Fri, 23 Sep 2011 06:13:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R72lM-0000sU-SE for qemu-devel@nongnu.org; Fri, 23 Sep 2011 06:13:45 -0400 From: Markus Armbruster References: <1314902275-5240-1-git-send-email-lcapitulino@redhat.com> <4E774636.7050500@redhat.com> <20110919110945.5a9cb43c@doriath> <4E7751B8.7040903@redhat.com> <4E7C5182.50108@redhat.com> Date: Fri, 23 Sep 2011 12:13:41 +0200 In-Reply-To: <4E7C5182.50108@redhat.com> (Kevin Wolf's message of "Fri, 23 Sep 2011 11:29:38 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH v1 0/6]: block: Add I/O status support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino Kevin Wolf writes: > Am 23.09.2011 10:55, schrieb Markus Armbruster: [...] >> Apropos enforcing. Currently, -drive accepts any werror and rerror >> action with if={ide,virtio,scsi,none}. We rely on device models not >> implementing an action to check and fail during initialization. >> scsi-generic and the floppy devices do. All the other qdevified devices >> don't, and that's broken. >> >> Are werror and rerror really host state? > > If you want to convince me of the opposite, show me the real device that > implements them. It's an honest question. > In fact, for the implementation of rerror/werror the very same thing is > true as you say about I/O status updates. Other than being easy to > implement, there is really no reason to do it in the devices. The block > layer could just as well stop the VM and queue the requests for > resubmission when the VM is restarted. Of course, you can't keep > migration compatibility when doing such a fundamental change to the > design, but if you take the host state thing serious, this is what you > should do. Good answer. I'd love to have it spelled out in the code.