From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:44008)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mark.cave-ayland@ilande.co.uk>) id 1Yipg6-00042E-V6
	for qemu-devel@nongnu.org; Thu, 16 Apr 2015 15:42:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mark.cave-ayland@ilande.co.uk>) id 1Yipg5-0001Y5-Su
	for qemu-devel@nongnu.org; Thu, 16 Apr 2015 15:42:22 -0400
Message-ID: <5530108F.9000607@ilande.co.uk>
Date: Thu, 16 Apr 2015 20:42:07 +0100
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
MIME-Version: 1.0
References: <552FE6C8.106@linux.vnet.ibm.com>
In-Reply-To: <552FE6C8.106@linux.vnet.ibm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] ppc64 not resuming with v2.3.0-rc3
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>, agraf@suse.de, qemu-devel <qemu-devel@nongnu.org>, qemu-ppc@nongnu.org

On 16/04/15 17:43, Stefan Berger wrote:

> The culprit patch seems to be the following commit. If I remove these
> changes from the tip of the tree it works again (on SLOF level):
> 
> commit 2360b6e84f78d41fa0f76555a947148b73645259
> Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> Date:   Mon Feb 9 22:40:48 2015 +0000
> 
>     target-ppc: force update of msr bits in cpu_post_load
> 
>     Since env->msr has already been restored by the time cpu_post_load
> is called,
>     make sure that ppc_store_msr() is explicitly called with all msr
> bits except
>     MSR_TGPR marked as invalid.
> 
>     This solves the issue where MSR flags aren't set correctly when
> restoring a VM
>     snapshot, in particular the internal env->excp_prefix value when
> MSR_EP has
>     been altered by a guest.
> 
>     Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>     Signed-off-by: Alexander Graf <agraf@suse.de>
> 
> diff --git a/target-ppc/machine.c b/target-ppc/machine.c
> index c801b82..3921012 100644
> --- a/target-ppc/machine.c
> +++ b/target-ppc/machine.c
> @@ -159,6 +159,7 @@ static int cpu_post_load(void *opaque, int version_id)
>      PowerPCCPU *cpu = opaque;
>      CPUPPCState *env = &cpu->env;
>      int i;
> +    target_ulong msr;
> 
>      /*
>       * We always ignore the source PVR. The user or management
> @@ -190,7 +191,12 @@ static int cpu_post_load(void *opaque, int version_id)
>          /* Restore htab_base and htab_mask variables */
>          ppc_store_sdr1(env, env->spr[SPR_SDR1]);
>      }
> -    hreg_compute_hflags(env);
> +
> +    /* Mark msr bits except MSR_TGPR invalid before restoring */
> +    msr = env->msr;
> +    env->msr ^= ~(1ULL << MSR_TGPR);
> +    ppc_store_msr(env, msr);
> +
>      hreg_compute_mem_idx(env);
> 
>      return 0;
> 
> 
>    Stefan
> 
> PS: Sorry for the late notice (-rc3), but I only started doing things
> with ppc64 a few days ago.

Hmmmm the fix is correct in that internal MSR variables need to be
updated post-restore (as noted in the message above it was the exception
prefix variables that weren't updated by having MSR_EP set).

Maybe on ppc64 there is another bit similar to MSR_TGPR that needs to be
excluded? Alex, any thoughts?


ATB,

Mark.