From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCA7h-0004xA-5y for qemu-devel@nongnu.org; Thu, 13 Sep 2012 10:10:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCA7X-0001vS-8h for qemu-devel@nongnu.org; Thu, 13 Sep 2012 10:10:29 -0400 Message-ID: <5051E947.9080306@suse.de> Date: Thu, 13 Sep 2012 16:10:15 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1347505041-27411-1-git-send-email-david@gibson.dropbear.id.au> <1347505041-27411-3-git-send-email-david@gibson.dropbear.id.au> In-Reply-To: <1347505041-27411-3-git-send-email-david@gibson.dropbear.id.au> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 02/13] pseries: Fix and cleanup CPU initialization and reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: qemu-ppc@nongnu.org, agraf@suse.de, qemu-devel@nongnu.org Am 13.09.2012 04:57, schrieb David Gibson: > The current pseries machine init function iterates over the CPUs at sev= eral > points, doing various bits of initialization. This is messy; these can > and should be merged into a single iteration doing all the necessary pe= r > cpu initialization. Worse, some of these initializations were setting = up > state which should be set on every reset, not just at machine init time= . > A few of the initializations simply weren't necessary at all. >=20 > This patch, therefore, moves those things that need to be to the > per-cpu reset handler, and combines the remainder into two loops over > the cpus (which also creates them). The second loop is for setting up > hash table information, and will be removed in a subsequent patch also > making other fixes to the hash table setup. >=20 > This exposes a bug in our start-cpu RTAS routine (called by the guest t= o > start up CPUs other than CPU0) under kvm. Previously, this function di= d > not make a call to ensure that it's changes to the new cpu's state were > pushed into KVM in-kernel state. We sort-of got away with this because > some of the initializations had already placed the secondary CPUs into = the > right starting state for the sorts of Linux guests we've been running. >=20 > Nonetheless the start-cpu RTAS call's behaviour was not correct and cou= ld > easily have been broken by guest changes. This patch also fixes it. >=20 > Signed-off-by: David Gibson Thanks for changing the comment, Reviewed-by: Andreas F=E4rber Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg