From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGaNI-0006JL-TS for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:15:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGaND-0006Iz-Ed for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:15:00 -0400 Received: from [199.232.76.173] (port=58054 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGaND-0006Iw-7V for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:14:55 -0400 Received: from mx20.gnu.org ([199.232.41.8]:41972) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MGaND-0003CO-0T for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:14:55 -0400 Received: from mail-bw0-f223.google.com ([209.85.218.223]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGaNB-00058b-WA for qemu-devel@nongnu.org; Tue, 16 Jun 2009 11:14:54 -0400 Received: by bwz23 with SMTP id 23so3687177bwz.34 for ; Tue, 16 Jun 2009 08:14:51 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <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> <20090615200552.GC782@redhat.com> Date: Tue, 16 Jun 2009 18:14:51 +0300 Message-ID: Subject: Re: [Qemu-devel] Register uhci_reset() callback. From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Avi Kivity , Paul Brook , qemu-devel@nongnu.org On 6/15/09, Gleb Natapov wrote: > 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. I see. The problem is in piix_pci interrupt handling, pci_irq_levels[] should be set to zero on reset.