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

[Benoît Canet]

flash_mapped reflect the bit 2 of a control register.

Peter, does this patch look better ?

commit 2fa7b11ee2b2532d00056d6bbc928c5162925e1d

Author: Benoît Canet <address@hidden>

Date:   Mon Oct 24 14:39:26 2011 +0200

    integratorcp: convert integratorcm to VMState

    

    Signed-off-by: Benoit Canet <address@hidden>

diff --git a/hw/integratorcp.c b/hw/integratorcp.c

index 9a289b4..4e51579 100644

--- a/hw/integratorcp.c

+++ b/hw/integratorcp.c

@@ -34,6 +34,42 @@ typedef struct {

     uint32_t fiq_enabled;

 } integratorcm_state;

 

+static void integratorcm_do_remap(integratorcm_state *s, int flash);

+

+static int integratorcm_post_load(void *opaque, int version_id)

+{

+    integratorcm_state *s = opaque;

+

+    if (s->cm_ctrl & 4) {

+        integratorcm_do_remap(s, 0);

+    }

+    /* ??? tlb_flush (cpu_single_env, 1); */

+    return 0;

+}

+

+static const VMStateDescription vmstate_integratorcm = {

+    .name = "integratorcm",

+    .version_id = 1,

+    .minimum_version_id = 1,

+    .minimum_version_id_old = 1,

+    .post_load = integratorcm_post_load,

+    .fields = (VMStateField[]) {

+        VMSTATE_UINT32(memsz, integratorcm_state),

+        VMSTATE_UINT32(cm_osc, integratorcm_state),

+        VMSTATE_UINT32(cm_ctrl, integratorcm_state),

+        VMSTATE_UINT32(cm_lock, integratorcm_state),

+        VMSTATE_UINT32(cm_auxosc, integratorcm_state),

+        VMSTATE_UINT32(cm_sdram, integratorcm_state),

+        VMSTATE_UINT32(cm_init, integratorcm_state),

+        VMSTATE_UINT32(cm_flags, integratorcm_state),

+        VMSTATE_UINT32(cm_nvflags, integratorcm_state),

+        VMSTATE_UINT32(int_level, integratorcm_state),

+        VMSTATE_UINT32(irq_enabled, integratorcm_state),

+        VMSTATE_UINT32(fiq_enabled, integratorcm_state),

+        VMSTATE_END_OF_LIST()

+    }

+};

+

 static uint8_t integrator_spd[128] = {

    128, 8, 4, 11, 9, 1, 64, 0,  2, 0xa0, 0xa0, 0, 0, 8, 0, 1,

    0xe, 4, 0x1c, 1, 2, 0x20, 0xc0, 0, 0, 0, 0, 0x30, 0x28, 0x30, 0x28, 0x40

@@ -547,6 +583,7 @@ static SysBusDeviceInfo core_info = {

     .init = integratorcm_init,

     .qdev.name  = "integrator_core",

     .qdev.size  = sizeof(integratorcm_state),

+    .qdev.vmsd = &vmstate_integratorcm,

     .qdev.props = (Property[]) {

         DEFINE_PROP_UINT32("memsz", integratorcm_state, memsz, 0),

         DEFINE_PROP_END_OF_LIST(),

On Tue, Nov 8, 2011 at 7:33 AM, Avi Kivity <address@hidden> wrote:

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.