From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiUYx-00032A-A9 for qemu-devel@nongnu.org; Wed, 04 Jan 2012 12:23:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiUYt-0007p1-20 for qemu-devel@nongnu.org; Wed, 04 Jan 2012 12:23:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiUYs-0007ou-Rd for qemu-devel@nongnu.org; Wed, 04 Jan 2012 12:23:39 -0500 Message-ID: <4F048B10.1060505@redhat.com> Date: Wed, 04 Jan 2012 19:23:28 +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> <4EEE25DA.2080400@redhat.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 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