[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Qemu-devel] [PATCH 5/5] vga-cirrus: Workaround during restore when using Xen.
On Fri, Nov 25, 2011 at 11:51, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote: >> On Thu, Nov 24, 2011 at 18:30, Stefano Stabellini >> <stefano.stabellini@xxxxxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |