From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGITL-00007c-BZ for qemu-devel@nongnu.org; Mon, 15 Jun 2009 16:08:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGITG-0008VU-K3 for qemu-devel@nongnu.org; Mon, 15 Jun 2009 16:08:02 -0400 Received: from [199.232.76.173] (port=32937 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGITG-0008VG-6p for qemu-devel@nongnu.org; Mon, 15 Jun 2009 16:07:58 -0400 Received: from mx2.redhat.com ([66.187.237.31]:41900) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGITF-0006Fg-Eu for qemu-devel@nongnu.org; Mon, 15 Jun 2009 16:07:57 -0400 Date: Mon, 15 Jun 2009 23:05:52 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Register uhci_reset() callback. Message-ID: <20090615200552.GC782@redhat.com> References: <20090611084808.GA19508@redhat.com> <4A3674F5.5080403@redhat.com> <20090615170201.GA3964@redhat.com> <200906151856.28009.paul@codesourcery.com> <20090615181622.GA782@redhat.com> <20090615193054.GB782@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Avi Kivity , Paul Brook , qemu-devel@nongnu.org On Mon, Jun 15, 2009 at 10:50:04PM +0300, Blue Swirl wrote: > On 6/15/09, Gleb Natapov wrote: > > On Mon, Jun 15, 2009 at 09:57:54PM +0300, Blue Swirl wrote: > > > On 6/15/09, Gleb Natapov wrote: > > > > On Mon, Jun 15, 2009 at 06:56:26PM +0100, Paul Brook wrote: > > > > > > May be, but in this case after previous patch to reset interrupt level > > > > > > for each device at PCI bridge level was rejected on the premise that > > > > > > device should lower its own irq line on reset and since patches started > > > > > > flowing in to do just that, I did not expect that eloquent explanation > > > > > > would be needed for such trivial and obviously correct change. > > > > > > > > > > This argument makes no sense. The fact that you'd recently submitted very > > > > > similar looking patches which either got rejected or need modification is a > > > > > good argument for providing an explanation. How else are we supposed to know > > > > > that you're not just making the same mistake again? > > > > > > > > They was not even "similar looking". Have you followed the discussion > > > > that those patches generated? Look at this commit and especially its commit > > > > message: 32c86e95b. This commit is a direct result of the discussion > > > > previous patches generated. Look at my patch now. Looks similar, no? So > > > > people with commit permissions can follow lower standards that we mere > > > > mortals? > > > > > > I find nothing wrong with your commit message (for completeness, it > > > could mention that it installs a reset handler). > > > > > > > It does in subject line. Subject line goes to log message with git-am. > > > > > > > Maybe lowering the irq should actually be unnecessary, qemu_irq is not > > > equal to hardware interrupt line. > > > > Racing irq from pci device will call piix3_set_irq(). piix3_set_irq() > > will remember current level in pci_irq_levels[]. The PIC line will be > > triggered if one of pci_irq_levels[] is set (depends on piix3 config). > > If for instance pci_irq_levels[0] and pci_irq_levels[1] are mapped to > > the same PIC irq and during reset pci_irq_levels[1] == 1, but device > > that drives pci_irq_levels[0] is initialized first the device will not > > be able to lower irq line. > > Maybe, but then the other device is reset also piix3 at some point. Because interrupt line is stuck a guest can't get to the point where it loads a driver to the second device. For outside observer the guest just hangs. -- Gleb.