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
