Re: [Qemu-devel] [Qemu-ppc] Unable to loadvm on qemu-system-ppc -M g3beige (keyboard freeze)

[Alexander Graf <agraf@suse.de>]

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 <agraf@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