From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcKkI-0006BR-5N for qemu-devel@nongnu.org; Sun, 18 Dec 2011 12:41:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RcKkH-0002BV-4u for qemu-devel@nongnu.org; Sun, 18 Dec 2011 12:41:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40471) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcKkG-0002BQ-PL for qemu-devel@nongnu.org; Sun, 18 Dec 2011 12:41:57 -0500 Message-ID: <4EEE25DA.2080400@redhat.com> Date: Sun, 18 Dec 2011 19:41:46 +0200 From: Avi Kivity MIME-Version: 1.0 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> <4EE609BF.1070307@siemens.com> <4EE617BA.4030102@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Anthony Perard , Jan Kiszka , Xen Devel , QEMU-devel 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