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

[Avi Kivity <avi@redhat.com>]

On 01/04/2012 06:38 PM, Stefano Stabellini wrote:
>
> > 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).

Sorry, I don't follow, please be specific as to which type of address
you're referring to:

ram_addr?
physical address (as seen by guest - but if it is not mapped, what does
your last sentence mean?)
something else?

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

I'm missing some context.  Can you please explain in more detail?

Note that with the memory API changes, ram addresses are going away. 
There will not be a linear space for guest RAM.  We'll have
(MemoryRegion *, offset) pairs that will be mapped into discontiguous
guest physical address ranges (perhaps with overlaps).

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