On 24 September 2012 10:18, Peter A. G. Crosthwaite <peter.crosthwa...@petalogix.com> wrote: > @@ -296,10 +297,13 @@ static void ssd0323_save(QEMUFile *f, void *opaque) > qemu_put_be32(f, s->remap); > qemu_put_be32(f, s->mode); > qemu_put_buffer(f, s->framebuffer, sizeof(s->framebuffer)); > + > + qemu_put_be32(f, ss->cs); > } > > static int ssd0323_load(QEMUFile *f, void *opaque, int version_id) > { > + SSISlave *ss = SSI_SLAVE(opaque); > ssd0323_state *s = (ssd0323_state *)opaque; > int i; > > @@ -321,6 +325,8 @@ static int ssd0323_load(QEMUFile *f, void *opaque, int > version_id) > s->mode = qemu_get_be32(f); > qemu_get_buffer(f, s->framebuffer, sizeof(s->framebuffer)); > > + ss->cs = qemu_get_be32(f); > + > return 0; > }
This looks odd. The cs field isn't part of the ssd0323_state, so it shouldn't be ssd0303_save/load's job to save and restore it. Contrast the way the vmstate-based devices don't directly save/restore cs but defer to VMSTATE_SSI_SLAVE. -- PMM