qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6 3/4] cpu/apic: drop icc bus/bridge


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v6 3/4] cpu/apic: drop icc bus/bridge
Date: Fri, 22 May 2015 13:56:22 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

On Fri, May 22, 2015 at 03:44:53PM +0800, Chen Fan wrote:
> On 05/20/2015 10:53 PM, Igor Mammedov wrote:
> >On Wed, 20 May 2015 10:40:48 +0800
> >Zhu Guihua <address@hidden> wrote:
> >
> >>From: Chen Fan <address@hidden>
> >>
> >>After CPU hotplug has been converted to BUS-less hot-plug infrastructure,
> >>the only function ICC bus performs is to propagate reset to LAPICs. However
> >>LAPIC could be reset by its parent (CPU) directly when CPU is being reset.
> >>Do so and drop ~200LOC of not needed anymore ICCBus related code.
> >>
> >>Signed-off-by: Chen Fan <address@hidden>
> >>Signed-off-by: Zhu Guihua <address@hidden>
> >This patch regresses emulated APIC,
> >during RHEL7 boot:
> >
> >[    1.073487] ------------[ cut here ]------------
> >[    1.074019] WARNING: at arch/x86/kernel/apic/apic.c:1401 
> >setup_local_APIC+0x268/0x320()
> >[    1.075011] Modules linked in:
> >[    1.076474] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0.sort+ #100
> >[    1.077012] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> >rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014
> >[    1.078011]  0000000000000000 00000000d1b49dbb ffff88007c787da8 
> >ffffffff81649983
> >[    1.082011]  ffff88007c787de0 ffffffff810b3241 0000000000000001 
> >0000000000000000
> >[    1.085012]  00000000000000f0 0000000000000000 00000000ffffffff 
> >ffff88007c787df0
> >[    1.088012] Call Trace:
> >[    1.089019]  [<ffffffff81649983>] dump_stack+0x19/0x1b
> >[    1.090017]  [<ffffffff810b3241>] warn_slowpath_common+0x61/0x80
> >[    1.091015]  [<ffffffff810b336a>] warn_slowpath_null+0x1a/0x20
> >[    1.092016]  [<ffffffff81089ae8>] setup_local_APIC+0x268/0x320
> >[    1.093019]  [<ffffffff81ad4f02>] native_smp_prepare_cpus+0x294/0x35b
> >[    1.094018]  [<ffffffff81ac1133>] kernel_init_freeable+0xbb/0x217
> >[    1.095017]  [<ffffffff81636fe0>] ? rest_init+0x80/0x80
> >[    1.096015]  [<ffffffff81636fee>] kernel_init+0xe/0x180
> >[    1.097016]  [<ffffffff816598fc>] ret_from_fork+0x7c/0xb0
> >[    1.098016]  [<ffffffff81636fe0>] ? rest_init+0x80/0x80
> >[    1.099017] ---[ end trace d99eba50bffa17c5 ]---
> >
> >
> >void setup_local_APIC(void)
> >...
> >         } while (queued && max_loops > 0);
> >         WARN_ON(max_loops <= 0);                     <=== here
> >...
> >
> >reproducer:
> >   qemu-system-x86_64 -enable-kvm -m 2048  -smp 4 -machine 
> > kernel_irqchip=off rhel7.img
> >or just slower plain TCG
> >   qemu-system-x86_64 -m 2048 -smp 4 rhel7.img
> >
> >it happens only on VM startup, there isn't any warning when booting after 
> >reset.
> Hi Igor, Thanks for you pointing it out.
> 
> I had found that the problem appeared after we moved the apic reset into cpu
> reset.
> 
> the original operation is that there are devices (such as hpet, rtc) reset
> before apic reset,
> when these devices reset, it would send irq to apic, before the change, the
> apic reset
> is behind these devices reset. so the apic register is set to default
> values.
> 
> but after the change, thanks to the cpu reset is before the qemu system
> reset which causes
> that the apic reset ahead the other devices reset. but before guest boot up,
> the irq request
> should be rejected.  so when linux enable local apic, it would found there
> were irr requests.
> then cause warn_on.
> 
[...]
>  static void x86_cpu_apic_realize(X86CPU *cpu, Error **errp)
> @@ -2801,8 +2793,6 @@ static void x86_cpu_realizefn(DeviceState *dev, Error
> **errp)
>      }
> 
>  #ifndef CONFIG_USER_ONLY
> -    qemu_register_reset(x86_cpu_machine_reset_cb, cpu);
> -
>      if (cpu->env.features[FEAT_1_EDX] & CPUID_APIC || smp_cpus > 1) {
>          x86_cpu_apic_create(cpu, &local_err);
>          if (local_err != NULL) {
> diff --git a/vl.c b/vl.c
> index 15bccc4..0c53053 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1618,6 +1618,7 @@ void qemu_devices_reset(void)
>      QTAILQ_FOREACH_SAFE(re, &reset_handlers, entry, nre) {
>          re->func(re->opaque);
>      }
> +    reset_all_vcpus();
>  }

What about all the other architectures and machines that may expect
different reset ordering, and that already register their own CPU reset
handlers?

If x86 has specific CPU reset ordering requirements, we should be able
to ensure the expected ordering in x86-specific code (in pc.c?), not
hardcode reset ordering for all machines.

(BTW, what was the motivation to move qemu_register_reset() from pc.c to
target-i386/cpu.c? The only architectures that register reset handlers
inside the CPU code are x86 and s390x, all others register reset
handlers inside machine code.)

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]