From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 2/2] KVM: x86: allow BSP to handle INIT IPIs like APs do Date: Mon, 8 Feb 2016 17:40:58 +0100 Message-ID: <56B8C51A.2070505@redhat.com> References: <1454539876-8310-1-git-send-email-brogers@suse.com> <1454539876-8310-2-git-send-email-brogers@suse.com> <56B8B057.5050900@redhat.com> <56B8B29C.8060600@web.de> <56B860E202000048001251D8@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: namit@cs.technion.ac.il To: Bruce Rogers , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jan Kiszka Return-path: In-Reply-To: <56B860E202000048001251D8@prv-mh.provo.novell.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 08/02/2016 17:33, Bruce Rogers wrote: >>> >> >>> >> KVM_MP_STATE_INIT_RECEIVED is what Intel calls the "wait for SIPI" >>> >> state. The BSP never gets a SIPI, it goes straight to 0xFFFFFFF0 >>> >> instead. Can you explain the problem more in detail? >> > >> > I suspect this is about sending INIT-SIPI from another CPU, directed to >> > the BSP, isn't it? We may have to differentiate between CPU (including >> > system) reset and that IPI case. > That is correct. In looking over the KVM code which deals with BSP, this was > the only place which seemed wrong to me wrt special casing for BSP outside the > context of initial system initialization / reset. As far as I understand the > BSP shouldn't be treated differently in this case. See 8.4.2 of the SDM: If the MP protocol has completed and a BSP is chosen, subsequent INITs (either to a specific processor or system wide) do not cause the MP protocol to be repeated. Instead, each logical processor examines its BSP flag (in the IA32_APIC_BASE MSR) to determine whether it should execute the BIOS boot-strap code (if it is the BSP) or enter a wait-for-SIPI state (if it is an AP). So it is correct to treat the BSP differently here, I think. Paolo