From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 2/2] KVM: x86: allow BSP to handle INIT IPIs like APs do Date: Mon, 8 Feb 2016 18:53:45 +0100 Message-ID: <56B8D629.60206@web.de> 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> <56B8C51A.2070505@redhat.com> <56B8703502000048001251F9@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="glvkEXS3LEeBEmLBRSWwrhOvpwoNfbO2U" Cc: namit@cs.technion.ac.il To: Bruce Rogers , Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: In-Reply-To: <56B8703502000048001251F9@prv-mh.provo.novell.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --glvkEXS3LEeBEmLBRSWwrhOvpwoNfbO2U Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-02-08 18:38, Bruce Rogers wrote: >>>> On 2/8/2016 at 10:27 AM, Bruce Rogers wrote:=20 >>>>> On 2/8/2016 at 09:40 AM, Paolo Bonzini wrote:= =20 >> >>> >>> On 08/02/2016 17:33, Bruce Rogers wrote: >>>>>>>> >>>>>>>> KVM_MP_STATE_INIT_RECEIVED is what Intel calls the "wait for SIP= I" >>>>>>>> state. The BSP never gets a SIPI, it goes straight to 0xFFFFFFF= 0 >>>>>>>> instead. Can you explain the problem more in detail? >>>>>> >>>>>> I suspect this is about sending INIT-SIPI from another CPU, direct= ed to >>>>>> the BSP, isn't it? We may have to differentiate between CPU (inclu= ding >>>>>> 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 o= utside=20 >>> the >>>> context of initial system initialization / reset. As far as I unders= tand 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 INIT= s >>> (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. >> >> I had read that, but I though this was speaking from the perspective o= f the >> SMP aware BIOS code only. In other words, the BIOS would sidetrack AP'= s >> (based on BSP flag not being present), while BSP would be allowed to g= o=20 >> through >> the regular BIOS code, checking for reset case, etc. An OS on the othe= r hand >> would be free to treat all x86 processors equally, once it has booted = into >> fully symmetrical mode. >> I certainly could be wrong about my above interpretation, but with the= se >> changes I'm proposing, things work well for the test case of manually = >> onlining >> the BSP after the crash kernel has been started (via kexec -e on a AP = >> processor >> with maxcpus=3D1 on the crash kernel command line). From looking throu= gh the >> kernel git history it appears this sequence of events was explicitly=20 >> supported >> quite a while ago, and we've got a customer who uses this for fast rec= overy=20 >> from >> a guest kernel crash. >> >> Bruce >=20 > I mean kexec - p ... above, not kexec -e. Sorry about that. How does real HW behave with your kexec case? Did you try this? Jan --glvkEXS3LEeBEmLBRSWwrhOvpwoNfbO2U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAla41ikACgkQitSsb3rl5xTxigCg4VSHlq+I/nDvYkgohA5Nik/J WrcAnRfRpzGxXgg9pm1hN7KY3tVZpNBS =FB6u -----END PGP SIGNATURE----- --glvkEXS3LEeBEmLBRSWwrhOvpwoNfbO2U--