Re: [Xen-devel] [Qemu-devel] [PATCH 5/5] vga-cirrus: Workaround during restore when using Xen.

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

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