From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qj4dF-0000OH-MS for qemu-devel@nongnu.org; Tue, 19 Jul 2011 03:22:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qj4dD-0000bs-Rd for qemu-devel@nongnu.org; Tue, 19 Jul 2011 03:22:17 -0400 Received: from mail.valinux.co.jp ([210.128.90.3]:50553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qj4dD-0000bk-81 for qemu-devel@nongnu.org; Tue, 19 Jul 2011 03:22:15 -0400 Date: Tue, 19 Jul 2011 16:22:12 +0900 From: Isaku Yamahata Message-ID: <20110719072212.GA29608@valinux.co.jp> References: <1311020546-9769-1-git-send-email-weil@mail.berlios.de> <20110719023910.GC25737@valinux.co.jp> <4E251C99.9000600@mail.berlios.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E251C99.9000600@mail.berlios.de> Subject: Re: [Qemu-devel] [PATCH] Fix duplicate device reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel@nongnu.org On Tue, Jul 19, 2011 at 07:56:41AM +0200, Stefan Weil wrote: > Am 19.07.2011 04:39, schrieb Isaku Yamahata: >> Thank you for addressing this. Similar patches were proposed and >> weren't merged unfortunately. >> >> The reason why the qdev_register_reset() in vl.c is to keep the reset order. >> The reset for main_system_bus shouldn't registered by qbus_create_inplace(). >> But the check, bus != main_system_bus, doesn't work as intended because >> main_system_bus is NULL in early qdev creation. >> So there are possible ways for the fix. >> >> - Don't care the reset order >> your patch + >> remove "if (bus != main_system_bus)" in qbus_create_inplace() >> >> - keep the reset order >> - instantiate main_system_bus early. >> So the check, bus != main_system_bus in qbus_create_inplace(), will work. >> or >> - fix the check, bus != main_system_bus in qbus_create_inplace(), somehow >> >> thanks, > > Hi, > > my patch does not remove sysbus_get_default(), > so the reset order is kept because main_system_bus > is instantiated by this call. Yes, your patch doesn't change the order from the existing code. I think it's not intended one. During machine creation, someone may call sysbus_get_default(). So the reset for main_system_bus may not be the lastly registered. The changeset of 80376c3f tries to keep the reset order, but failed. That's the issue. -- yamahata