On Fri, Nov 25, 2011 at 11:51, Stefano Stabellini <stefano.stabell...@eu.citrix.com> wrote: >> On Thu, Nov 24, 2011 at 18:30, Stefano Stabellini >> <stefano.stabell...@eu.citrix.com> wrote: >> > >> >> @@ -2784,9 +2796,11 @@ static void cirrus_reset(void *opaque) >> >> } >> >> s->vga.cr[0x27] = s->device_id; >> >> >> >> - /* Win2K seems to assume that the pattern buffer is at 0xff >> >> - initially ! */ >> >> - memset(s->vga.vram_ptr, 0xff, s->real_vram_size); >> >> + if (!runstate_check(RUN_STATE_PREMIGRATE)) { >> >> + /* Win2K seems to assume that the pattern buffer is at 0xff >> >> + initially ! */ >> >> + memset(s->vga.vram_ptr, 0xff, s->real_vram_size); >> >> + } >> >> >> > >> > this is not too bad, I suppose that the videoram is going to be written >> > again at restore time anyway so at least it saves some cycles >> >> Actually, I think the next time that this vram will be written again >> is, when the guest is actually "waked-up" and wrote something there. >> Otherwise, the "restore" of the vram is done before QEMU start. So, >> the memset could leave some weard stuff the screen (a white screen?). > > So this is the succession of events: > > - vga_common_init > allocates the videoram > > - cirrus_reset > sets set videoram to 0xff > > - load_vmstate > the old videoram is copied over, overwriting what cirrus_reset has done > > therefore setting the videoram to 0xff when resuming is a waste of > efforts
Ooops, I reduce my answer to the only Xen case. So I agree with you. -- Anthony PERARD