From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ11I-0000d6-O9 for qemu-devel@nongnu.org; Mon, 14 Nov 2011 13:12:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQ11H-0007us-Pu for qemu-devel@nongnu.org; Mon, 14 Nov 2011 13:12:36 -0500 Received: from acsinet15.oracle.com ([141.146.126.227]:21076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ11H-0007uf-L4 for qemu-devel@nongnu.org; Mon, 14 Nov 2011 13:12:35 -0500 Date: Mon, 14 Nov 2011 13:11:54 -0500 From: Konrad Rzeszutek Wilk Message-ID: <20111114181154.GC14875@phenom.dumpdata.com> References: <1319814456-8158-1-git-send-email-anthony.perard@citrix.com> <1319814456-8158-8-git-send-email-anthony.perard@citrix.com> <20111110212840.GA23643@phenom.dumpdata.com> <20111111180542.GA6408@phenom.dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Xen-devel] [PATCH V3 07/10] Introduce Xen PCI Passthrough, qdevice (1/3) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Anthony Perard , Guy Zana , Xen Devel , Allen Kay , QEMU-devel On Mon, Nov 14, 2011 at 11:09:31AM +0000, Stefano Stabellini wrote: > On Fri, 11 Nov 2011, Konrad Rzeszutek Wilk wrote: > > > > > + hw_error("Internal error: Invalid write emulation " > > > > > + "return value[%d]. I/O emulator exit.\n", rc); > > > > > > > > Oh. I hadn't realized this, but you are using hw_error. Which is > > > > calling 'abort'! Yikes. Is there no way to recover from this? Say return 0xfffff? > > > > > > In qemu-xen-traditionnal, it was an exit(1). I do not know the > > > consequence of a bad write, and I can not return anythings. So I suppose > > > that the guest would know that somethings wrong only on the next read. > > > > > > Instead of abort();, I can just do nothing and return. Or we could unplug > > > the device from QEMU. > > > > > > Any preference? > > > > I think this calls for an experiment. If Linux still functions if you completly > > unplug the device, then I would say unplug it (b/c in most likelyhood the reason > > you can't write is b/c the host has unplugged the device). > > It would make sense to try to PCI hot-unplug the device, however > considering that it requires guest support, it cannot be used to safely > handle an error like this one. Also it requires some interactions that > might not be possible anymore at this point. > I would destroy the domain instead, using a graceful shutdown if > possible. Something similar to libxl_domain_shutdown. Sounds good, and we should also print something prudent to the log _why_ we just killed the guest. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH V3 07/10] Introduce Xen PCI Passthrough, qdevice (1/3) Date: Mon, 14 Nov 2011 13:11:54 -0500 Message-ID: <20111114181154.GC14875@phenom.dumpdata.com> References: <1319814456-8158-1-git-send-email-anthony.perard@citrix.com> <1319814456-8158-8-git-send-email-anthony.perard@citrix.com> <20111110212840.GA23643@phenom.dumpdata.com> <20111111180542.GA6408@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Stefano Stabellini Cc: Anthony Perard , Guy Zana , Xen Devel , Allen Kay , QEMU-devel List-Id: xen-devel@lists.xenproject.org On Mon, Nov 14, 2011 at 11:09:31AM +0000, Stefano Stabellini wrote: > On Fri, 11 Nov 2011, Konrad Rzeszutek Wilk wrote: > > > > > + hw_error("Internal error: Invalid write emulation " > > > > > + "return value[%d]. I/O emulator exit.\n", rc); > > > > > > > > Oh. I hadn't realized this, but you are using hw_error. Which is > > > > calling 'abort'! Yikes. Is there no way to recover from this? Say return 0xfffff? > > > > > > In qemu-xen-traditionnal, it was an exit(1). I do not know the > > > consequence of a bad write, and I can not return anythings. So I suppose > > > that the guest would know that somethings wrong only on the next read. > > > > > > Instead of abort();, I can just do nothing and return. Or we could unplug > > > the device from QEMU. > > > > > > Any preference? > > > > I think this calls for an experiment. If Linux still functions if you completly > > unplug the device, then I would say unplug it (b/c in most likelyhood the reason > > you can't write is b/c the host has unplugged the device). > > It would make sense to try to PCI hot-unplug the device, however > considering that it requires guest support, it cannot be used to safely > handle an error like this one. Also it requires some interactions that > might not be possible anymore at this point. > I would destroy the domain instead, using a graceful shutdown if > possible. Something similar to libxl_domain_shutdown. Sounds good, and we should also print something prudent to the log _why_ we just killed the guest.