qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMSta


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState
Date: Tue, 08 Nov 2011 14:38:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

On 11/08/2011 02:30 PM, Peter Maydell wrote:
> On 8 November 2011 12:21, Avi Kivity <address@hidden> wrote:
> > On 11/08/2011 02:15 PM, Peter Maydell wrote:
> >> This needs to be in the MemoryRegion core implementation, please.
> >
> > Right; see the memory/mutators branch.  I plan to push this as soon as
> > everything is converted.
>
> OK, then this save/restore patch should wait until that has landed.

Please don't add interdependencies, especially as I can't promise a firm
date as to when everything is converted (however I'll take this
opportunity to remind you that patches, especially for omap, are more
welcome than I can possibly articulate).

> >> Ideally memory.c should just ensure that the memory hierarchy
> >> is saved and restored without devices having to do anything.
> >
> > That's a bit far-fetched - I don't want the memory core involved in
> > save/restore.  But if/when we integrate the memory core into QOM, then
> > yes, that layer can take care of it.  If we have an observable attribute
> > (that fires off a callback when changed), we can link memory API
> > properties into that attribute.
>
> The memory hierarchy is a visible part of the state which can
> change as the guest does things -- it has to get saved and
> restored somehow. I think it would be better done in the core
> where it will always be done right, rather than relying on
> each device to handle it correctly (especially since it's not
> always obvious if it's been missed out from the device.)

We agree, the only difference is in what "core" refers to.  I don't want
memory.c do become intermingled with everything else.  It should be in a
separate layer.  Devices would then talk to this layer, and not to the
gluing by themselves as they have to now.

Or maybe memory.c will be layered on top of QOM, and then it can take
care of everything.  I really don't know QOM well enough to say. 
Copying Anthony for more insight.

-- 
error compiling committee.c: too many arguments to function




reply via email to

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