qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] Unable to loadvm on qemu-system-ppc -M g3bei


From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] [Qemu-devel] Unable to loadvm on qemu-system-ppc -M g3beige (keyboard freeze)
Date: Thu, 18 Dec 2014 21:36:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

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.


ATB,

Mark.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]