From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDAnS-0005Bf-P4 for qemu-devel@nongnu.org; Mon, 19 Jan 2015 06:47:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDAnN-00048j-Mw for qemu-devel@nongnu.org; Mon, 19 Jan 2015 06:47:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDAnN-00048d-Ep for qemu-devel@nongnu.org; Mon, 19 Jan 2015 06:47:01 -0500 Message-ID: <54BCEEA6.2060003@redhat.com> Date: Mon, 19 Jan 2015 12:46:46 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1421650918-90656-1-git-send-email-kathy.wangting@huawei.com> In-Reply-To: <1421650918-90656-1-git-send-email-kathy.wangting@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qdev: The sequence of devices added to bus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ting Wang , qemu-devel@nongnu.org On 19/01/2015 08:01, Ting Wang wrote: > diff --git a/hw/core/qdev.c b/hw/core/qdev.c > index 901f289..7d830a6 100644 > --- a/hw/core/qdev.c > +++ b/hw/core/qdev.c > @@ -89,7 +89,7 @@ static void bus_add_child(BusState *bus, DeviceState *child) > kid->child = child; > object_ref(OBJECT(kid->child)); > > - QTAILQ_INSERT_HEAD(&bus->children, kid, sibling); > + QTAILQ_INSERT_TAIL(&bus->children, kid, sibling); > > /* This transfers ownership of kid->child to the property. */ > snprintf(name, sizeof(name), "child[%d]", kid->index); > Hi Ting, I think this patch had already been submitted in the past. The result of the discussion was that: 1) the behavior you report was not reproduced consistently. This means that it is either a race condition, or it depends on the kernel release. In fact I think a race condition here is expected, and thus the patch wouldn't entirely fix the problem. 2) This would be a change in the guest interface, so it is unfortunately too late to do it unconditionally. You could do it only for new machine types, but it would be a very intrusive change with very high probability of breaking something---much more than anything else we do for new machine types. So it is probably not a good idea. Paolo