From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfTxN-0004LA-82 for qemu-devel@nongnu.org; Tue, 07 Apr 2015 09:54:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfTxI-0001YF-Nh for qemu-devel@nongnu.org; Tue, 07 Apr 2015 09:54:21 -0400 Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:35797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfTxI-0001V7-Ga for qemu-devel@nongnu.org; Tue, 07 Apr 2015 09:54:16 -0400 Received: by widdi4 with SMTP id di4so18398884wid.0 for ; Tue, 07 Apr 2015 06:54:15 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5523E183.9000805@redhat.com> Date: Tue, 07 Apr 2015 15:54:11 +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> <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> <5523DE35.5050103@suse.de> In-Reply-To: <5523DE35.5050103@suse.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Eduardo Habkost , Nadav Amit , mst@redhat.com, qemu-devel@nongnu.org, Igor Mammedov , nadav.amit@gmail.com, rth@twiddle.net On 07/04/2015 15:40, Andreas Färber wrote: > Am 07.04.2015 um 15:29 schrieb Paolo Bonzini: >> On 07/04/2015 15:24, Andreas Färber wrote: >>>>> /* We hard-wire the BSP to the first CPU. */ >>>>> if (s->cpu_index == 0) { >>>>> apic_designate_bsp(cpu->apic_state); >>>>> } >>> I know, that's what this patch is changing, and I am saying that by the >>> 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. >> >> 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. You cannot tell, since the MP protocol reruns immediately after a full reset. I think we do this in apic_cpu_reset to avoid mess with the initialization order of the APIC and CPU. > 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. Yes, I agree, but as you know very well the propagation of signals (be it "reset" or "realize") is a mess. Even if you make the APIC a QOM child of the CPU, this doesn't mean that qdev reset (which is post-order) propagates to the APIC before propagating to the CPU. > 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. Well, actually I did post it for inclusion in 2.3 since it affected only KVM and it would be ugly to have 4.0 fail kvm-unit-tests with all existing QEMU releases. Paolo