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 <ag...@suse.de> 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
