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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Sun, 18 Dec 2011, Avi Kivity wrote:
> 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.

That is not an issue, the current code supports this case.


> 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()

I cannot see how this is going to fix the save/restore issue we are
trying to solve.
The problem, unfortunately very complex, is that at restore time the
videoram is already allocated at the physical address it was mapped
before the save operation. If it was not mapped, it is at the end of the
physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
allocate it).

So the issue is that the videoram appears to qemu as part of the
physical memory of the guest at an unknown address.

The proposal of introducing early_savevm would easily solve this last
problem: letting us know where the videoram is. The other problem, the
fact that under Xen the videoram would be already allocated while under
native it would not, remains unsolved. 
We cannot simply allocate the videoram twice because the operation
would fail (Xen would realize that we are trying to allocate more memory
than it we are supposed to, returning an error).
However, once we know where the videoram is, we could probably figure out
a smart (see hacky) way to avoid allocating it twice without changes to
the cirrus code.



> 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?

Nope, a guest moving the cirrus BAR should work correctly even now.

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