qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore wh


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.
Date: Thu, 05 Jan 2012 16:49:02 -0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]