From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NoGmy-0005OI-Oi for qemu-devel@nongnu.org; Sun, 07 Mar 2010 08:45:00 -0500 Received: from [199.232.76.173] (port=39323 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NoGmy-0005OA-F0 for qemu-devel@nongnu.org; Sun, 07 Mar 2010 08:45:00 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NoGmw-0004lF-RQ for qemu-devel@nongnu.org; Sun, 07 Mar 2010 08:45:00 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:37135) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NoGmw-0004l1-Be for qemu-devel@nongnu.org; Sun, 07 Mar 2010 08:44:58 -0500 Message-ID: <4B93ADD2.1000405@web.de> Date: Sun, 07 Mar 2010 14:44:50 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20100303160022.GG16909@redhat.com> <4B8EF1FE.7020000@web.de> <20100304064723.GH16909@redhat.com> <4B8F6E12.8040707@web.de> <20100304083549.GI16909@redhat.com> <4B8F9B11.60804@siemens.com> <20100304120354.GK16909@redhat.com> <20100307063643.GN16909@redhat.com> <4B938481.70307@web.de> In-Reply-To: <4B938481.70307@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig79AD400163EA54AC12BAEED6" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH v4 03/10] x86: Extend validity of cpu_is_bsp List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Marcelo Tosatti , Avi Kivity , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig79AD400163EA54AC12BAEED6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Gleb Natapov wrote: >> On Thu, Mar 04, 2010 at 02:03:54PM +0200, Gleb Natapov wrote: >>>> BTW, do real systems allow to hot plug BSP as well? Or how is the ca= se >>>> handled when you unplug the BSP and then reboot the box? >>>> >>> Did you mean hot unplug BSP? OS determines what CPU is BSP by checkin= g >>> BSP bit in APIC base register. My guess is that there is some pin on = CPU >>> which value is mirrored as BSP bit in APIC base register. Board may h= ave >>> some logic to check what sockets are populated and chose one of them = as >>> BSP by pulling its pin up. But this is only guess. >>> >> Actually this is much more simple: >> SDM 8.4.1: >> The MP initialization protocol defines two classes of processors: the= >> bootstrap processor (BSP) and the application processors (APs). Follo= wing >> a power-up or RESET of an MP system, system hardware dynamically sele= cts >> one of the processors on the system bus as the BSP. The remaining >> processors are designated as APs. >> And by "hardware" they mean CPUs themselves over apic BUS. >=20 > That should be straightforward, will have a look. I just want to ensure= > that cpu_is_bsp delivers a valid result all the time. Otherwise we will= > run into ordering issues again once some new user of this services show= s up. >=20 =2E..but you have to explain to me how CPU hotplugging in current qemu-kv= m is supposed to work. 'cpu_set n offline' does not have any visible effect: Linux still allows to bring such a CPU online again, and it is also brought up again after reset. Besides this, I would probably need some other OS to test offlining the BSP - Linux does not appear to support it. Jan --------------enig79AD400163EA54AC12BAEED6 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.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuTrdcACgkQitSsb3rl5xRcBQCgjEwE6KSCac+1N1mdYV58rLtc 8EoAn2VWlpyJwGSVpghyjox74VD5JpT5 =HBrW -----END PGP SIGNATURE----- --------------enig79AD400163EA54AC12BAEED6--