From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXIFb-0000CT-9X for qemu-devel@nongnu.org; Wed, 11 Feb 2009 11:47:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXIFZ-0000Ai-Kz for qemu-devel@nongnu.org; Wed, 11 Feb 2009 11:47:50 -0500 Received: from [199.232.76.173] (port=55179 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXIFZ-0000AY-GW for qemu-devel@nongnu.org; Wed, 11 Feb 2009 11:47:49 -0500 Received: from lizzard.sbs.de ([194.138.37.39]:24692) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LXIFY-0006Km-TJ for qemu-devel@nongnu.org; Wed, 11 Feb 2009 11:47:49 -0500 Message-ID: <49930130.5050409@siemens.com> Date: Wed, 11 Feb 2009 17:47:44 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1234360034-19459-1-git-send-email-glommer@redhat.com> <4992DF4B.6070109@siemens.com> <20090211143732.GA27729@poweredge.glommer> <4992E499.8050502@siemens.com> <4992EF12.3000103@redhat.com> In-Reply-To: <4992EF12.3000103@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] remove smaller slots if registering a bigger one Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Glauber Costa , aliguori@us.ibm.com Avi Kivity wrote: > Jan Kiszka wrote: >>> Which is fine. I'd prefer it to be here, so we can analyse it case by >>> case. >>> The old memory code for kvm was totally messy, in part because we >>> tried to >>> hug the world at once, with some code paths that were almost never hit. >>> >>> Slot management can easily get very complicated. and trying to come up >>> with a solution that accounts for all problems at once may backfire >>> on us. >>> >>> >> >> Well, then "fix" all users... >> > > Making memory management in qemu symmetric (any > cpu_register_physical_memory() must be followed by a > cpu_unregister_physical_memory() with the same parameters) is a good idea. > Then all devices should track their - potentially guest-defined - mappings and revert them on reset? I think handling this in the lower layer is more convenient. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux