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

[Jan Kiszka <jan.kiszka@xxxxxx>]

On 2012-01-05 15:50, Avi Kivity wrote:
>> Let me summarize what we have come up with so far:
>>
>> - we move the call to xen_register_framebuffer before
>> memory_region_init_ram in vga_common_init;
>>
>> - we prevent xen_ram_alloc from allocating a second framebuffer on
>> restore, checking for mr == framebuffer;
>>
>> - we avoid memsetting the framebuffer on restore (useless anyway, the
>> videoram is going to be loaded from the savefile in the general case);
>>
>> - we introduce a xen_address field to cirrus_vmstate and we use it
>> to map the videoram into qemu's address space and update vram_ptr in
>> cirrus_post_load.
>>
>>
>> Does it make sense? Do you agree with the approach?
> 
> Yes and yes.

To me this still sounds like a cirrus-only xen workaround that
nevertheless spreads widely.

Again, what speaks against migrating the information Xen needs before
creating the machine or a single device? That would only introduce a
generic concept of an (optional) "early", let's call it
"accelerator-related" vmstate and would allow Xen to deal with all the
specifics behind the curtain.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel