Today virtio-blk dataplane uses a 1:1 device-per-thread model. Now that
IOThreads have been introduced we can generalize this to N:M devices per
threads.
This patch drops thread code from dataplane in favor of running inside
an IOThread AioContext.
As a bonus we solve the case where a guest keep
This causes the following bug during managedsave of s390 with a guest that has
multiple disks with dataplane.
(gdb) bt
#0 object_deinit (type=0x0, obj=0x807e8750) at
/home/cborntra/REPOS/qemu/qom/object.c:410
#1 object_finalize (data=0x807e8750) at
/home/cborntra/REPOS/qemu/qom/object.c:424
#
Hmm, now I have trouble getting the whole thing started (Dont know how I was
able to start the
guest from below).
The problem seems to be that qdev->name is always "virtio-blk".
So this code in virtio_blk_data_plane_create will always add a child called
"virtio-blk", which
obviously doesnt work
Il 19/03/2014 12:02, Christian Borntraeger ha scritto:
Error *local_err = NULL;
s->internal_iothread = true;
object_add(TYPE_IOTHREAD, vdev->name, NULL, NULL, &local_err);
This should instead use object_new and object_property_add_child to add
an "internal-iothread" ch
On Mon, Mar 17, 2014 at 04:52:59PM +0100, Christian Borntraeger wrote:
> This causes the following bug during managedsave of s390 with a guest that
> has multiple disks with dataplane.
>
> (gdb) bt
> #0 object_deinit (type=0x0, obj=0x807e8750) at
> /home/cborntra/REPOS/qemu/qom/object.c:410
> #
On 20/03/14 11:13, Stefan Hajnoczi wrote:
> On Mon, Mar 17, 2014 at 04:52:59PM +0100, Christian Borntraeger wrote:
>> This causes the following bug during managedsave of s390 with a guest that
>> has multiple disks with dataplane.
>>
>> (gdb) bt
>> #0 object_deinit (type=0x0, obj=0x807e8750) at
