Re: [Qemu-devel] [PULL 0/7] X86 patches

[Eduardo Habkost]

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 <address@hidden> 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 (address@hidden) 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 (address@hidden) 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 (address@hidden)
> >     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