From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzVxS-0001RG-OR for qemu-devel@nongnu.org; Fri, 12 Dec 2014 14:33:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XzVxJ-0003Nj-2T for qemu-devel@nongnu.org; Fri, 12 Dec 2014 14:32:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzVxI-0003Nf-Rr for qemu-devel@nongnu.org; Fri, 12 Dec 2014 14:32:49 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBCJWkYv024584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 12 Dec 2014 14:32:47 -0500 Date: Fri, 12 Dec 2014 19:32:43 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20141212193242.GF2328@work-vm> References: <1418227041-28151-1-git-send-email-pbonzini@redhat.com> <20141212173044.GD2328@work-vm> <548B370A.9070107@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548B370A.9070107@redhat.com> Subject: Re: [Qemu-devel] [PATCH] kvm/apic: fix 2.2->2.1 migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: imammedo@redhat.com, qemu-devel@nongnu.org * Paolo Bonzini (pbonzini@redhat.com) wrote: > > > On 12/12/2014 18:30, Dr. David Alan Gilbert wrote: > > OK, let me just check that I get this.... > > > > It gets reset to 0 already in kvm_apic_realize > > (before this patch -- after this patch it's only done in reset) > > > then we do the common init > > Then as part of starting up auxiliary processors we send an INIT > interrupt, that resets the APIC and... > > > that sets it to !bsp - so 1 for most CPUs > > then you're adding this so that a specific APIC implementation (kvm) > > can nobble it back to 0 again? > > Yes. That's needed because this APIC implementation does not use the > field at all. > > > and on the load side it's forced to zero by apic_pre_load. > > Yes. That's the common case for the !APIC implementation because it > gets to zero as soon as te OS starts. OK; yep, that's OK. Reviewed-by: Dr. David Alan Gilbert > > Paolo -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK