[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 0/7] X86 patches
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PULL 0/7] X86 patches |
Date: |
Tue, 10 Mar 2015 14:57:18 -0300 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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
- [Qemu-devel] [PULL 3/7] target-i386: Eliminate unnecessary get_cpuid_vendor() function, (continued)
- [Qemu-devel] [PULL 3/7] target-i386: Eliminate unnecessary get_cpuid_vendor() function, Eduardo Habkost, 2015/03/09
- [Qemu-devel] [PULL 4/7] target-i386: Remove unused APIC ID default code, Eduardo Habkost, 2015/03/09
- [Qemu-devel] [PULL 5/7] target-i386: Move CPUX86State::cpuid_apic_id to X86CPU::apic_id, Eduardo Habkost, 2015/03/09
- [Qemu-devel] [PULL 6/7] target-i386: Move APIC ID compatibility code to pc.c, Eduardo Habkost, 2015/03/09
- [Qemu-devel] [PULL 7/7] target-i386: Require APIC ID to be explicitly set before CPU realize, Eduardo Habkost, 2015/03/09
- Re: [Qemu-devel] [PULL 0/7] X86 patches, Peter Maydell, 2015/03/10
- Re: [Qemu-devel] [PULL 0/7] X86 patches,
Eduardo Habkost <=