From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfQqZ-0005s7-Jk for qemu-devel@nongnu.org; Tue, 07 Apr 2015 06:35:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfQqV-0003co-KP for qemu-devel@nongnu.org; Tue, 07 Apr 2015 06:35:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfQqV-0003Xx-Dg for qemu-devel@nongnu.org; Tue, 07 Apr 2015 06:35:03 -0400 Message-ID: <5523B2C6.5080601@redhat.com> Date: Tue, 07 Apr 2015 12:34:46 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1427932716-11800-1-git-send-email-namit@cs.technion.ac.il> <551D3768.9090404@redhat.com> <5523AE38.6000701@suse.de> In-Reply-To: <5523AE38.6000701@suse.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] target-i386: clear bsp bit when designating bsp List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?windows-1252?Q?Andreas_F=E4rber?= , Nadav Amit , mst@redhat.com, qemu-devel@nongnu.org Cc: nadav.amit@gmail.com, Eduardo Habkost , rth@twiddle.net On 07/04/2015 12:15, Andreas F=E4rber wrote: >>> >> diff --git a/target-i386/cpu.c b/target-i386/cpu.c >>> >> index b2d1c95..03b33cf 100644 >>> >> --- a/target-i386/cpu.c >>> >> +++ b/target-i386/cpu.c >>> >> @@ -2714,9 +2714,7 @@ static void x86_cpu_reset(CPUState *s) >>> >> =20 >>> >> #if !defined(CONFIG_USER_ONLY) >>> >> /* We hard-wire the BSP to the first CPU. */ >>> >> - if (s->cpu_index =3D=3D 0) { >>> >> - apic_designate_bsp(cpu->apic_state); >>> >> - } >>> >> + apic_designate_bsp(cpu->apic_state, s->cpu_index =3D=3D 0); >>> >> =20 >>> >> s->halted =3D !cpu_is_bsp(cpu); >>> >> =20 >>> >> >> >=20 >> > Thanks, applied locally. > I don't understand why this is necessary: The cpu_index doesn't change, > therefore the BSP designation won't change either. It can change at runtime, though, if you're using the KVM in-kernel LAPIC. Paolo Is this a hot-unplug > preparation? Or is a KVM-specific call missing here? Either way, the > commit message could use some clarification.