From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58645) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1k56-0006Zr-VD for qemu-devel@nongnu.org; Thu, 18 Dec 2014 18:02:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1k50-000601-RI for qemu-devel@nongnu.org; Thu, 18 Dec 2014 18:02:04 -0500 Message-ID: <54935CE5.4090201@suse.de> Date: Fri, 19 Dec 2014 00:01:57 +0100 From: Alexander Graf MIME-Version: 1.0 References: <54915835.6030508@ilande.co.uk> <549159B6.6000006@suse.de> <54915F28.1090001@ilande.co.uk> <549164F5.5080902@suse.de> <5492DCAB.4050907@ilande.co.uk> <5492E8D6.3040503@suse.de> <549348E7.3020401@ilande.co.uk> In-Reply-To: <549348E7.3020401@ilande.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] Unable to loadvm on qemu-system-ppc -M g3beige (keyboard freeze) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland , Peter Maydell Cc: "qemu-ppc@nongnu.org" , qemu-devel On 18.12.14 22:36, Mark Cave-Ayland wrote: > On 18/12/14 15:13, Peter Maydell wrote: > >> On 18 December 2014 at 14:46, Alexander Graf wrote: >>> On 18.12.14 14:54, Mark Cave-Ayland wrote: >>>> So it looks like several of the device MemoryRegions aren't being added >>>> after the "loadvm". Does this mean there is an object lifecycle issue >>>> here in that some of the initialisation needs to be done in realizefn >>>> rather than initfn or vice-versa? >>> >>> I always thought we're going through both - initfn and realizefn with >>> normal system boot as well as vmstate load. >> >> Yes. Migration incoming and vmstate load both work as "create, >> initialize, realize and reset system as normal, then do state >> load before running it". >> >>> So that means that the additional mappings above must be runtime >>> creations that aren't saved and restored properly. >> >> Looks likely. Memory regions themselves don't have any saved or >> reloaded state, so it's the responsibility of the devices that >> create and control them to ensure that they're set up correctly >> again on state load. This is trivial for most devices which >> just have an unchanging set, but controller chip equivalents >> that allow the guest to map and unmap stuff need to be cleverer. > > I think that the problem is that the macio device doesn't have any > declared vmstate - presumably since no vmstate is saved for that device > then it doesn't appear in the loadvm restore list and so the object is > never re-initialised. > > I can probably have a go at trying to sort out the VMStateDescription > (and maybe see how easy it is to convert some of these things to QOM) > but it seems that MACIOState has an array of qemu_irqs embedded directly > in it which I'm not sure how to handle. > > Can anyone point me towards an example device the best current practice > for either wiring up qemu_irqs via QOM or how to represent them within a > VMStateDescription? In general it seems that SPARC and PPC mostly use > old APIs so there is a distinct lack of good reference examples for > devices I am familiar with. Why exactly would you need to wire up the qemu_irqs? If the lines are asserted at the point of migration, the MPIC model should migrate over the fact that a line is pending, no? Alex