From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jp1ST-0000hB-NV for qemu-devel@nongnu.org; Thu, 24 Apr 2008 09:25:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jp1SQ-0000gB-Cp for qemu-devel@nongnu.org; Thu, 24 Apr 2008 09:25:50 -0400 Received: from [199.232.76.173] (port=35333 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jp1SO-0000fm-Tb for qemu-devel@nongnu.org; Thu, 24 Apr 2008 09:25:49 -0400 Received: from yw-out-1718.google.com ([74.125.46.156]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jp1SO-0001h6-8Q for qemu-devel@nongnu.org; Thu, 24 Apr 2008 09:25:48 -0400 Received: by yw-out-1718.google.com with SMTP id 4so1545390ywq.82 for ; Thu, 24 Apr 2008 06:25:38 -0700 (PDT) Message-ID: <5d6222a80804240625q20abdd77v7ffe235f3135a333@mail.gmail.com> Date: Thu, 24 Apr 2008 10:25:38 -0300 From: "Glauber Costa" Subject: Re: [Qemu-devel] Re: [kvm-devel] [PATCH 0/3] Qemu crashes with pci passthrough In-Reply-To: <5d6222a80804191411v3cf59bd5ic1c5ebcd2f660fe6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <12084217752458-git-send-email-gcosta@redhat.com> <4808CBDB.3030206@qumranet.com> <5d6222a80804191411v3cf59bd5ic1c5ebcd2f660fe6@mail.gmail.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kvm-devel@lists.sourceforge.net, mtosatti@redhat.com, aurelien@aurel32.net, Glauber de Oliveira Costa On Sat, Apr 19, 2008 at 6:11 PM, Glauber Costa wrote: > > On Fri, Apr 18, 2008 at 1:27 PM, Avi Kivity wrote: > > > > Glauber de Oliveira Costa wrote: > > > > > Hi, > > > I've got some qemu crashes while trying to passthrough an ide device > > > to a kvm guest. After some investigation, it turned out that > > register_ioport_{read/write} will abort on errors instead of returning > > > a meaningful error. > > > > > > However, even if we do return an error, the asynchronous nature of pci > > > config space mapping updates makes it a little bit hard to treat. > > > > > > This series of patches basically treats errors in the mapping functions in > > > the pci layer. If anything goes wrong, we unregister the pci device, > > unmapping > > > any mappings that happened to be sucessfull already. > > > > > > After these patches are applied, a lot of warnings appears. And, you know, > > > everytime there is a warning, god kills a kitten. But I'm not planning on > > > touching the other pieces of qemu code for this until we set up (or not) > > in > > > this solution > > > > > > Comments are very welcome, specially from qemu folks (since it is a bit > > invasive) > > > > > > > > > > > > > Have you considered, instead of rolling back the changes you already made > > before the failure, to have a function which checks if an ioport > > registration will be successful? This may simplify the code. > > > Yes, I did. > > Basic problem is that I basically could not find this information > handy until we were deep in the stack, right before calling the update > mapping functions. I turned out preferring this option. I can, > however, take a fresh look at that. > Looked at this again, and it does seem to me that we don't have too much to gain from a "test-before" solution. We definitely can't test it reliably until update_mappings arrive, (since the mapping can change) and by this time, the pci device is already registered, and we would have to de-register it anyway. There is room for "improvement" (with a wide definition of improvement) if we test all the ports of a device in advance (inside update_mappings) instead of a port-by-port basis. We could get rid of the flag, but it would be traded off by another complexities. So unless someone have a very direct alternate solution for this I'm failing to see, I do advocate for those humble patches. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."