On 07/12/2015 14:02, Fam Zheng wrote: > On Mon, 12/07 12:29, Cornelia Huck wrote: >> On Mon, 7 Dec 2015 18:59:27 +0800 >> Fam Zheng <f...@redhat.com> wrote: >> >>> The official way of enabling dataplane is through the "iothread" >>> property that references an iothread object created by "-object >>> iothread". Since the old "x-data-plane=on" way now even crashes, it's >>> probably easier to just drop it: >>> >>> $ qemu-system-x86_64 -drive file=null-co://,id=d0,if=none \ >>> -device virtio-blk-pci,drive=d0,x-data-plane=on >>> >>> ERROR:/home/fam/work/qemu/qom/object.c:1515: >>> object_get_canonical_path_component: assertion failed: (obj->parent != NULL) >>> Aborted >> >> Do we understand yet why this crashes, btw? > > I think it's because with x-data-plane=on, virtio-blk initialize an object > that > doesn't have a parent, therefore it doesn't have a valid "canonical path > component" thing, which is different from objects created with "-object" CLI. > I'm not very familiar with the QOM semantics here. > >> >>> >>> Signed-off-by: Fam Zheng <f...@redhat.com> >>> --- >>> hw/block/dataplane/virtio-blk.c | 15 ++------------- >>> hw/block/virtio-blk.c | 1 - >>> include/hw/virtio/virtio-blk.h | 1 - >>> 3 files changed, 2 insertions(+), 15 deletions(-) >>> >> >> No general objection to removing x-data-plane; but this probably wants >> a mention on the changelog as x-data-plane has been described in >> various howtos etc. over the years. > > Yes, that is a good point. I don't know if it's too rushing in removing it > for > 2.5 (this is just posted as one option) and we'll have to count on QOM experts > for the fix, if it is.
The solution would be to add object_property_add_child to virtio_blk_data_plane_create, between object_initialize and user_creatable_complete. But I think this patch is ok for 2.5. Paolo