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 08:33:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

On 11/08/2011 04:07 AM, Peter Maydell wrote:
> 2011/10/26 Peter Maydell <address@hidden>:
> > On 25 October 2011 12:09, Benoît Canet <address@hidden> wrote:
> >> +static const VMStateDescription vmstate_integratorcm = {
> >> +    .name = "integratorcm",
> >> +    .version_id = 1,
> >> +    .minimum_version_id = 1,
> >> +    .minimum_version_id_old = 1,
> >> +    .fields = (VMStateField[]) {
> >> +        VMSTATE_UINT32(memsz, integratorcm_state),
> >> +        VMSTATE_BOOL(flash_mapped, integratorcm_state),
> >
> > This raises a question. flash_mapped here is a flag which just
> > tracks whether the associated MemoryRegion is currently mapped
> > or unmapped. Do we need to do anything special to ensure that
> > the MemoryRegion itself is reset to the correct mapped/unmapped
> > state on restore?
> >
> > I recall discussing this kind of thing with Avi on IRC but I
> > can't remember what the conclusion was.
>
> Avi, ping? I'm still interested in the answer to this question.

Sorry, missed this. Yes, you need to ensure the memory region mapping
reflects flash_mapped.

btw, is flash_mapped a real device state (corresponds to a real memory
bit on the device) or just an artefact?  It's usually a bad idea to cast
implementation artefacts in vmstate concrete.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




reply via email to

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