From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfTjg-0002jM-5o for qemu-devel@nongnu.org; Tue, 07 Apr 2015 09:40:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfTjc-0003HL-1g for qemu-devel@nongnu.org; Tue, 07 Apr 2015 09:40:12 -0400 Received: from cantor2.suse.de ([195.135.220.15]:32798 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfTjb-0003G9-Sm for qemu-devel@nongnu.org; Tue, 07 Apr 2015 09:40:08 -0400 Message-ID: <5523DE35.5050103@suse.de> Date: Tue, 07 Apr 2015 15:40:05 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1427932716-11800-1-git-send-email-namit@cs.technion.ac.il> <551D3768.9090404@redhat.com> <5523AE38.6000701@suse.de> <5523B2C6.5080601@redhat.com> <5523B518.5050902@suse.de> <5523B755.2080909@redhat.com> <5523BB00.3040404@suse.de> <5523C62E.6010507@suse.de> <20150407151448.0ec7484d@igors-macbook-pro.local> <5523DA7B.9060008@suse.de> <5523DBC6.5000102@redhat.com> In-Reply-To: <5523DBC6.5000102@redhat.com> Content-Type: text/plain; charset=utf-8 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: Paolo Bonzini Cc: Eduardo Habkost , mst@redhat.com, Nadav Amit , qemu-devel@nongnu.org, Igor Mammedov , nadav.amit@gmail.com, rth@twiddle.net Am 07.04.2015 um 15:29 schrieb Paolo Bonzini: > On 07/04/2015 15:24, Andreas F=C3=A4rber wrote: >>>> /* We hard-wire the BSP to the first CPU. */ >>>> if (s->cpu_index =3D=3D 0) { >>>> apic_designate_bsp(cpu->apic_state); >>>> } >> I know, that's what this patch is changing, and I am saying that by th= e >> same logic the CPU has no business fiddling with the APIC's apicbase >> field when the APIC's reset is touching that very same field. >=20 > That's exactly what a real CPU does on power up or #RESET, though. Does the APIC retain its BSP bit value on #RESET though? I doubt it. It feels we're awkwardly working around qdev reset semantics here... If you say the CPU must be in charge, then we should assure that the APIC is reset before the CPU designates it and not have the APIC reset callback retain such bits. Admittedly, if this were for-2.3 (as which it is not marked) then this patch may be the least intrusive. But it isn't and I've been preparing to refactor the CPU-APIC relationship, so I really want to get it right long-term. Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=C3=BCrnberg)