From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55672) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvtWa-0000Tt-1m for qemu-devel@nongnu.org; Fri, 22 May 2015 16:26:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvtWW-0005g3-7U for qemu-devel@nongnu.org; Fri, 22 May 2015 16:26:31 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37130 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvtWW-0005f0-15 for qemu-devel@nongnu.org; Fri, 22 May 2015 16:26:28 -0400 Message-ID: <555F90E8.1090700@suse.de> Date: Fri, 22 May 2015 22:26:16 +0200 From: =?windows-1252?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <20150520165318.4ee310e7@nial.brq.redhat.com> <555EDE75.4010300@cn.fujitsu.com> <20150522165622.GF28075@thinpad.lan.raisama.net> In-Reply-To: <20150522165622.GF28075@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 3/4] cpu/apic: drop icc bus/bridge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Chen Fan Cc: Zhu Guihua , izumi.taku@jp.fujitsu.com, qemu-devel@nongnu.org, pbonzini@redhat.com, guz.fnst@cn.fujitsu.com, Igor Mammedov Am 22.05.2015 um 18:56 schrieb Eduardo Habkost: > On Fri, May 22, 2015 at 03:44:53PM +0800, Chen Fan wrote: >> 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 !=3D 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(); >> } >=20 > What about all the other architectures and machines that may expect > different reset ordering, and that already register their own CPU reset > handlers? >=20 > 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. +1 In particular pseries has special ordering requirements. > (BTW, what was the motivation to move qemu_register_reset() from pc.c t= o > 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.) I don't remember the motivation, it was Anthony overturning my objection against that exception from the rule though. If we can bring x86 or the other targets back in line, feel free to make an RFC. I still have an old branch with initial reset support for alpha and rth had a patch to that effect, too. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)