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

[Mark Cave-Ayland]

On 18/12/14 23:01, Alexander Graf wrote:

> 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 <address@hidden> 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?

It seems that I've misunderstood something mentioned earlier in the
thread, i.e. that loadvm also does the create, initialize, realize and
reset cycle. At least issuing "loadvm" in the monitor doesn't seem to do
that as far as I can see here? Otherwise I could see how recreating
qemu_irqs via the old-style init() functions every time "loadvm" is
issued would cause quite a bit of chaos.

Taking a different approach with a debugger this morning I think I may
have just figured out what's going on with the macio device - more to
follow soon I hope.


ATB,

Mark.