From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756152AbcBHRyI (ORCPT ); Mon, 8 Feb 2016 12:54:08 -0500 Received: from mout.web.de ([212.227.15.4]:65434 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755259AbcBHRyE (ORCPT ); Mon, 8 Feb 2016 12:54:04 -0500 Subject: Re: [PATCH 2/2] KVM: x86: allow BSP to handle INIT IPIs like APs do To: Bruce Rogers , Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org 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> Cc: namit@cs.technion.ac.il From: Jan Kiszka Message-ID: <56B8D629.60206@web.de> Date: Mon, 8 Feb 2016 18:53:45 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <56B8703502000048001251F9@prv-mh.provo.novell.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="glvkEXS3LEeBEmLBRSWwrhOvpwoNfbO2U" X-Provags-ID: V03:K0:AcAp8koD2hx9XRpV82SAR2dmpD9cqafMavXuxTkW8thQJsJH7g8 8YiVLERUvYdOLUwRgWMed3xyzhL0QuVG6Tc7FFj6ZpnDQgtp1l9zLRpi7iwewtoYd69egmg BMubRHpVqxS85ohBERwCg+j7gvF9601Z0ITUEM5NhCLHImDZyinGYPmchaCq62Vrl6M6G0c hmA2D1MX2p0ju91yPPRKw== X-UI-Out-Filterresults: notjunk:1;V01:K0:OwW4MGrvn9Q=:rYow8HGcjMPuT83D7/ch3m y7mqOjFRkHYhGtI0c7DN+npC8TNfuNNpKOlIX9q2OhNqBkXJF4zULINfAoBwuAf9qN4ZEjTC2 nZnYyBo8WITXMrT94QhW2qo66JQBZvLzKTpNnvqobHI5g0Mvz1lPb6+C6bFSFFC5x6zD5cChg wVkDmqBIltQGO/I3eT5txjeA+dcBInK67WzSuONfrMZNLTfQnNBShWeOmujxBSm3KiXDq+Jtx c2sju51wHvzASEC+WpPoBHd8HNiLGwd6YJyqZ68uy2v41EZCzU4MOLnpVkV9hILdMxc5G+8dq Asiu86/5iUWh8kbi0C/sk+xQ+oMoWaB2ShfADmb1n6THExbkvOKOx4AX/SDG+PSCJiFi1E6fn 8lcCVA7d9+BSk212A9mCSm7NqjixPYjNTyD3c5ZVOh2MMhUGkfZ54fJ+juf2wDSTItQG+apEN 610HVHqPG8u/zZ55RsM7hxGw7VIMk4pqlDN5qMdMmbNLWFafpw+nj7FSNNTaKV3xeifp6uHN5 cbQFkLIMEtOa7tvjoPIc/6BagayY7+vGYkCpIBkhYAeKL27eYnQrXbf4c3s64bydJrIJ3IVU3 gkQNNFKN9PfmVUTpuDeBEjF/0hGq32nbXSFKGN9WOcvG8bzIveKSLyGnUWBZL1aVQkVml9joG 2fFDMQG+ih2hCDlvlDbTODsjMSP+q/gzGXBdchX9jlpMj68lz73UjRtwfeUqKgFKHHnyBtGos CvRIHhmppXUaSQSsFbDy1+GmXTbc8QWutk6j98lovO5Eozbai5f6eKQ/pWU= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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--