On Tue, Mar 10, 2015 at 11:16:36AM -0300, Eduardo Habkost wrote: > On Tue, Mar 10, 2015 at 11:44:22AM +0000, Peter Maydell wrote: > > On 9 March 2015 at 20:40, Eduardo Habkost <ehabk...@redhat.com> wrote: > > > The following changes since commit > > > 277263e1b320d759a760ba6c5ea75ec268f929e5: > > > > > > Merge remote-tracking branch > > > 'remotes/agraf/tags/signed-ppc-for-upstream' into staging (2015-03-09 > > > 14:04:14 +0000) > > > > > > are available in the git repository at: > > > > > > https://github.com/ehabkost/qemu.git tags/x86-pull-request > > > > > > for you to fetch changes up to 9886e834f47adabdbfd54ab606788ce7326e6779: > > > > > > target-i386: Require APIC ID to be explicitly set before CPU realize > > > (2015-03-09 16:30:03 -0300) > > > > > > ---------------------------------------------------------------- > > > X86 patches queued in the last few weeks. Mostly code cleanup and changes > > > on > > > code assigning APIC ID. > > > > > > ---------------------------------------------------------------- > > > > 'make check' fails for the i386 targets, apparently because qemu-system-i386 > > segfaults on startup: > > Ouch. > > But I couldn't reproduce it on my system using the tree at the tag > above. Was it a merge containing other changes that are not on qemu.git > yet? >
So, as I can't reproduce it I will try to understand what's happening below: > > > > > e104462:trusty:qemu-for-merges$ gdb --args > > ./build/all/i386-softmmu/qemu-system-i386 -display none > > [...] > > > > (gdb) r > > Starting program: > > /home/petmay01/linaro/qemu-for-merges/build/all/i386-softmmu/qemu-system-i386 > > -display none > > > > [...] > > > > Program received signal SIGSEGV, Segmentation fault. > > object_get_class (obj=obj@entry=0x0) at > > /home/petmay01/linaro/qemu-for-merges/qom/object.c:589 > > 589 return obj->class; So, obj is NULL here... > > (gdb) bt > > #0 object_get_class (obj=obj@entry=0x0) at > > /home/petmay01/linaro/qemu-for-merges/qom/object.c:589 > > #1 0x00005555556668c2 in apic_enable_tpr_access_reporting > > (dev=<optimized out>, enable=<optimized out>) > > at /home/petmay01/linaro/qemu-for-merges/hw/intc/apic_common.c:86 That means cpu->apic_state is NULL at: static void vapic_enable_tpr_reporting(bool enable) { VAPICEnableTPRReporting info = { .enable = enable, }; CPUState *cs; X86CPU *cpu; CPU_FOREACH(cs) { cpu = X86_CPU(cs); info.apic = cpu->apic_state; run_on_cpu(cs, vapic_do_enable_tpr_reporting, &info); } } vapic_enable_tpr_reporting() is called at: * vapic_prepare(), which is called at: * vapic_write() * Which is vapic_ops.write, so it should be triggered by guest code only * vapic_post_load() * Which should run only for loadvm/migration * vapic_reset() * Which is DeviceClass::reset for TYPE_VAPIC X86CPU::apic_state is set by x86_cpu_apic_create() (which checks for NULL and reports an error in that case), which is called by x86_cpu_realizefn(), but only if the CPU has CPUID_APIC set or smp_cpus > 1. CPUID_APIC is set on the default CPU model (qemu64), so it should be always called. Also, the TYPE_VAPIC object is created by apic_common_realize(), so no TYPE_VAPIC object should exist until a TYPE_*_APIC object is created and realized. So it looks like x86_cpu_apic_create() is really being called. Maybe what's happening here is that the reset handler for TYPE_VAPIC is being called too soon, even before x86_cpu_apic_create() returns? But why? This is not making a lot of sense to me, and the fact that I can't reproduce the error makes it more difficult. > > #2 0x000055555562f881 in flush_queued_work (cpu=0x5555562c6b00) > > at /home/petmay01/linaro/qemu-for-merges/cpus.c:871 > > #3 qemu_wait_io_event_common (cpu=cpu@entry=0x5555562c6b00) > > at /home/petmay01/linaro/qemu-for-merges/cpus.c:888 > > #4 0x0000555555630a27 in qemu_tcg_cpu_thread_fn (arg=<optimized out>) > > at /home/petmay01/linaro/qemu-for-merges/cpus.c:1024 > > #5 0x00007ffff0865182 in start_thread (arg=0x7fffdf99e700) at > > pthread_create.c:312 > > #6 0x00007ffff059200d in clone () at > > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > > (gdb) > > > > thanks > > -- PMM > > -- > Eduardo > -- Eduardo