All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, famz@redhat.com, mprivozn@redhat.com,
	bsd@redhat.com, qemu-stable@nongnu.org,
	Yang Hongyang <yanghy@cn.fujitsu.com>,
	Jason Wang <jasowang@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] vl: Delay initialization of memory backends
Date: Thu, 1 Sep 2016 14:39:37 -0300	[thread overview]
Message-ID: <20160901173937.GE1151@thinpad.lan.raisama.net> (raw)
In-Reply-To: <27ce8661-7e37-9533-cbee-6a0e6daeb165@redhat.com>

On Thu, Sep 01, 2016 at 05:41:52PM +0200, Paolo Bonzini wrote:
> On 01/09/2016 17:10, Eduardo Habkost wrote:
> > Ouch. It looks like the ordering requirements are messier than I
> > thought. vhost-user depends on the memory backends to be already
> > initialized.
> 
> You could also look at delaying initialization of vhost-user, not
> sending anything on the wire until after machine creation.

I was wishing the bug could be fixed without the need to touch
vhost, but I will take a look.

BTW, the vhost error is actually happening inside a VCPU thread,
after everything was supposed to be fully initialized.  Maybe the
memory listener logic in vhost.c is broken somehow?


Backtrace (after manually adding an abort() to help debugging):

#2  0x0000562ebf27feb5 in vhost_user_set_mem_table (dev=0x562ec0189630, mem=<optimized out>) at /home/ehabkost/rh/proj/virt/qemu/hw/virtio/vhost-user.c:308
#3  0x0000562ebf27e524 in vhost_dev_start (hdev=hdev@entry=0x562ec0189630, vdev=vdev@entry=0x562ec19aa4c0) at /home/ehabkost/rh/proj/virt/qemu/hw/virtio/vhost.c:1304
#4  0x0000562ebf264a6b in vhost_net_start (dev=0x562ec19aa4c0, net=0x562ec0189630) at /home/ehabkost/rh/proj/virt/qemu/hw/net/vhost_net.c:232
#5  0x0000562ebf264a6b in vhost_net_start (dev=dev@entry=0x562ec19aa4c0, ncs=0x562ec19f3750, total_queues=total_queues@entry=1)
    at /home/ehabkost/rh/proj/virt/qemu/hw/net/vhost_net.c:324
#6  0x0000562ebf261543 in virtio_net_set_status (status=6 '\006', n=0x562ec19aa4c0) at /home/ehabkost/rh/proj/virt/qemu/hw/net/virtio-net.c:151
#7  0x0000562ebf261543 in virtio_net_set_status (vdev=<optimized out>, status=<optimized out>) at /home/ehabkost/rh/proj/virt/qemu/hw/net/virtio-net.c:224
#8  0x0000562ebf278fc3 in virtio_set_status (vdev=vdev@entry=0x562ec19aa4c0, val=val@entry=6 '\006') at /home/ehabkost/rh/proj/virt/qemu/hw/virtio/virtio.c:760
#9  0x0000562ebf450cbe in virtio_pci_config_write (val=6, addr=18, opaque=0x562ec19a2180) at hw/virtio/virtio-pci.c:400
#10 0x0000562ebf450cbe in virtio_pci_config_write (opaque=0x562ec19a2180, addr=18, val=6, size=<optimized out>) at hw/virtio/virtio-pci.c:525
#11 0x0000562ebf234b98 in memory_region_write_accessor (mr=0x562ec19a2a10, addr=18, value=<optimized out>, size=1, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/ehabkost/rh/proj/virt/qemu/memory.c:525
#12 0x0000562ebf23309d in access_with_adjusted_size (addr=addr@entry=18, value=value@entry=0x7f1917a1c2c8, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access=0x562ebf234b20 <memory_region_write_accessor>, mr=0x562ec19a2a10, attrs=...) at /home/ehabkost/rh/proj/virt/qemu/memory.c:591
#13 0x0000562ebf236f4c in memory_region_dispatch_write (mr=mr@entry=0x562ec19a2a10, addr=18, data=<optimized out>, size=size@entry=1, attrs=attrs@entry=...)
    at /home/ehabkost/rh/proj/virt/qemu/memory.c:1275
#14 0x0000562ebf1f23b7 in address_space_write (mr=0x562ec19a2a10, l=<optimized out>, addr1=<optimized out>, len=1, buf=0x7f1917a1c3a7 "\006", attrs=..., addr=49170, as=0x562ebfb52aa0 <address_space_io>) at /home/ehabkost/rh/proj/virt/qemu/exec.c:2556
#15 0x0000562ebf1f23b7 in address_space_write (as=0x562ebfb52aa0 <address_space_io>, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>)
    at /home/ehabkost/rh/proj/virt/qemu/exec.c:2601
#16 0x0000562ebf1f295d in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., buf=buf@entry=0x7f1917a1c3a7 "\006", len=len@entry=1, is_write=is_write@entry=true) at /home/ehabkost/rh/proj/virt/qemu/exec.c:2703
#17 0x0000562ebf1f61b6 in address_space_stb (as=<optimized out>, addr=<optimized out>, val=<optimized out>, attrs=..., result=result@entry=0x0)
    at /home/ehabkost/rh/proj/virt/qemu/exec.c:3443
#18 0x0000562ebf2d6731 in helper_outb (env=<optimized out>, port=<optimized out>, data=<optimized out>) at /home/ehabkost/rh/proj/virt/qemu/target-i386/misc_helper.c:32
#19 0x00007f193a4b166d in code_gen_buffer ()
#20 0x0000562ebf1f96e3 in cpu_exec (itb=0x7f1937d85b50, itb=0x7f1937d85b50, cpu=0x562ec0199e80) at /home/ehabkost/rh/proj/virt/qemu/cpu-exec.c:166
#21 0x0000562ebf1f96e3 in cpu_exec (sc=0x7f1917a1c8e0, tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=0x7f1937d85b50, cpu=0x562ec0199e80)
    at /home/ehabkost/rh/proj/virt/qemu/cpu-exec.c:530
#22 0x0000562ebf1f96e3 in cpu_exec (cpu=cpu@entry=0x562ec0191c00) at /home/ehabkost/rh/proj/virt/qemu/cpu-exec.c:625
#23 0x0000562ebf21f66f in qemu_tcg_cpu_thread_fn (cpu=0x562ec0191c00) at /home/ehabkost/rh/proj/virt/qemu/cpus.c:1541
#24 0x0000562ebf21f66f in qemu_tcg_cpu_thread_fn () at /home/ehabkost/rh/proj/virt/qemu/cpus.c:1574
#25 0x0000562ebf21f66f in qemu_tcg_cpu_thread_fn (arg=<optimized out>) at /home/ehabkost/rh/proj/virt/qemu/cpus.c:1171
#26 0x00007f195417d5ca in start_thread () at /lib64/libpthread.so.0
#27 0x00007f194f0f4ead in clone () at /lib64/libc.so.6
(gdb) up
#2  0x0000562ebf27feb5 in vhost_user_set_mem_table (dev=0x562ec0189630, mem=<optimized out>) at /home/ehabkost/rh/proj/virt/qemu/hw/virtio/vhost-user.c:308
308             abort();
(gdb) p dev->mem->nregions 
$1 = 0
(gdb) 

-- 
Eduardo

  reply	other threads:[~2016-09-01 17:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-31 20:17 [Qemu-devel] [PATCH] vl: Delay initialization of memory backends Eduardo Habkost
2016-08-31 21:47 ` no-reply
2016-09-01 15:10   ` Eduardo Habkost
2016-09-01 15:41     ` Paolo Bonzini
2016-09-01 17:39       ` Eduardo Habkost [this message]
2016-09-01 19:34         ` Eduardo Habkost
2016-09-01 22:29           ` Bandan Das
2016-09-02  8:59           ` Paolo Bonzini
2016-09-02 14:04             ` Eduardo Habkost
2016-09-02 14:56               ` Paolo Bonzini
2016-09-02 18:10                 ` Eduardo Habkost
2016-09-05 11:53                   ` Paolo Bonzini
2016-09-01 16:52     ` Michal Privoznik
2016-09-01 17:26       ` Eduardo Habkost
2016-09-02  6:13     ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160901173937.GE1151@thinpad.lan.raisama.net \
    --to=ehabkost@redhat.com \
    --cc=bsd@redhat.com \
    --cc=famz@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mprivozn@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=yanghy@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.