[Qemu-devel] [PATCH] qdev: The sequence of devices added to bus

[Qemu-devel] [PATCH] qdev: The sequence of devices added to bus

[Ting Wang]

When add a qdev device to bus, bus_add_child will be called.
But in this function, the new device is inserted to the head 
of the list. That means the sequence will be reversed.

For example, if there are three virtio-scsi devices with
lun 0 to 2 in the same controller, in the Guest, device with
lun 0 is always named as sda, device with lun 1 is named as
sdc, and device with lun 2 is named as sdb. So the order is
different from the lun number.

Signed-off-by: Ting Wang <kathy.wangting@huawei.com>
---
 hw/core/qdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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);
-- 
1.8.5

Re: [Qemu-devel] [PATCH] qdev: The sequence of devices added to bus

[Paolo Bonzini]

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