From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
Date: Sun, 18 Dec 2011 19:41:46 +0200
Message-ID: <4EEE25DA.2080400@redhat.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>, Jan Kiszka <jan.kiszka@siemens.com>, Xen Devel <xen-devel@lists.xensource.com>, QEMU-devel <qemu-devel@nongnu.org>
List-Id: xen-devel@lists.xenproject.org

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