From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RinRG-0004iP-BR for qemu-devel@nongnu.org; Thu, 05 Jan 2012 08:33:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RinRF-0001NL-CG for qemu-devel@nongnu.org; Thu, 05 Jan 2012 08:33:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RinRF-0001NF-5c for qemu-devel@nongnu.org; Thu, 05 Jan 2012 08:33:01 -0500 Message-ID: <4F05A684.7000509@redhat.com> Date: Thu, 05 Jan 2012 15:32:52 +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> <4F048B10.1060505@redhat.com> <4F059C8C.2030303@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/05/2012 03:17 PM, Stefano Stabellini wrote: > > > The "solution" I am proposing is introducing an early_savevm set of > > > save/restore functions so that at restore time we can get to know at > > > what address the videoram is mapped into the guest address space. Once we > > > know the address we can remap it into qemu's address space and/or move it > > > to another guest physical address. > > > > Why can we not simply track it? For every MemoryRegion, have a field > > called xen_address which tracks its location in the Xen address space > > (as determined by the last call to xen_set_memory or qemu_ram_alloc). > > xen_address would be maintained by callbacks called from the memory API > > into xen-all.c. > > Nice and simple, I like it. > However we would still need an early_savevm mechanism to save and restore the > MemoryRegions, unless they already gets saved and restored somehow? MemoryRegions are instantiated by the devices, so they should be there (creating a MemoryRegion == calling qemu_ram_alloc() in the old days) > Maybe saving and restoring the list of MemoryRegions could be useful for > the generic case too? Unneeded, since they're an integral part of the devices. However, it would be good to have a list of the devices so we could send that over instead of relying on invoking qemu with the same command-line arguments on both sides - but that's something that qom is already tackling. > > > The problem of avoiding a second allocation remains, but could be > > > solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to > > > xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything > > > called "vga.vram" at restore time, and use the reference to the already > > > allocated videoram instead. > > > > Hacky > > Yes :/ xen_register_framebuffer() is slightly less hacky. > > The allocation is not driven by qemu then? > > At restore time, it is not. > > > > For the long term I suggest making qemu control the allocations (perhaps > > by rpcing dom0); otherwise how can you do memory hotplug or PCI cards > > with RAM (like ivshmem)? > > It is only the videoram (well, everything allocated with > qemu_ram_alloc_from_ptr actually) and only at restore time, because > the memory in question is being considered normal guest memory and > therefore it is saved and restored by the hypervisor. > Otherwise Qemu is the one that triggers these allocations, so there are > no issues with memory hotplug and pci passthrough. Okay. -- error compiling committee.c: too many arguments to function