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

[Avi Kivity]

On 12/12/2011 05:32 PM, Stefano Stabellini wrote:
> > Really, I think this is something inherently incompatible with the
> > current memory API. If Xen has this unfixable special "requirement"
> > (it's rather a design issue IMHO), adjust the API and adapt all devices.
> > Hot-fixing only a single one this way is no good idea long term.
>
> Fair enough.
> What about introducing a type of savevm state that is going to be
> restored before machine->init?
> This way we could save and restore our physmap and we could handle
> memory maps and allocations transparently.

There is no guarantee there is a physical mapping for the framebuffer. 
A guest could unmap the framebuffer, and its display should still be
valid.  It can even update it by using the cirrus bitblt functions.

I suggest doing the following:

1. keep cirrus code unchanged
2. when the framebuffer is first mapped into physical memory (as known
by your CPUPhysMemoryClient), copy it into a temporary buffer, map the
guest memory into memory_region_get_ram_ptr(), and copy the temporary
buffer into memory_region_get_ram_ptr()
3. when the framebuffer is unmapped, do the reverse: copy the
framebuffer out, mmap() some anonymous memory into
memory_region_get_ram_ptr(), and copy the temporary buffer into
memory_region_get_ram_ptr()

We can later add optimizations to avoid the copy, but correctness before
performance.  I think currently a guest moving its cirrus BAR will
break, no?

-- 
error compiling committee.c: too many arguments to function