From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37701) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yirj6-0004ws-T1 for qemu-devel@nongnu.org; Thu, 16 Apr 2015 17:53:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yirj5-0004Hc-Mx for qemu-devel@nongnu.org; Thu, 16 Apr 2015 17:53:36 -0400 Sender: Paolo Bonzini Message-ID: <55302F54.3030204@redhat.com> Date: Thu, 16 Apr 2015 23:53:24 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <552FE6C8.106@linux.vnet.ibm.com> <5530108F.9000607@ilande.co.uk> <5530125A.8030408@linux.vnet.ibm.com> <5530213E.7020704@ilande.co.uk> <553028A6.2060500@linux.vnet.ibm.com> In-Reply-To: <553028A6.2060500@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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger , Mark Cave-Ayland , agraf@suse.de, qemu-devel , qemu-ppc@nongnu.org On 16/04/2015 23:24, Stefan Berger wrote: > On 04/16/2015 04:53 PM, Mark Cave-Ayland wrote: >> On 16/04/15 20:49, Stefan Berger wrote: >>>> 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? >>> I want to add that I am running QEMU for ppc64 in emulation mode on a >>> x86_64 host. The suspend/resume problem, while in SLOF, did not exist in >>> QEMU v2.2, so I anticipate that this is a regression would also be >>> visible on QEMU on kvm, though a simple test on such a machine may show >>> different... >>> >>> Removing the patch solves the problem while in SLOF. Once booting into >>> Linux suspend/resume does not work - with qemu-system-ppc64 on x86_64 >>> host. Timestamps shown by Linux actually make a jump backwards and >>> ultimately Linux hangs. >> Just to clarify the terminology here, when you say suspend/resume are >> you talking about a hardware suspend/resume or issuing a savevm/loadvm >> sequence in the QEMU monitor? Are you able to provide further detail to >> reproduce your test case? > > I am using 'virsh save' to suspend the VM, 'virsh restore' to resume it, > so I am doing this on libvirt level. Ok, that's the equivalent of "migrate exec:cat>foo.save" and "-incoming 'exec:cat > This is the XML to just test suspend / resume while it is in SLOF. No > disk needed. > > > ppc-test > 3e17dcdb-4a22-49ed-b8f9-4df523d04bb3 > 1310720 > 1310720 > 1 > > /machine > > > hvm > > > > > destroy > restart > restart > > /usr/bin/qemu-system-ppc64 > >
function='0x0'/> > > > > > > > >