From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXIOP-0005e6-KZ for qemu-devel@nongnu.org; Wed, 11 Feb 2009 11:56:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXIOO-0005de-7u for qemu-devel@nongnu.org; Wed, 11 Feb 2009 11:56:57 -0500 Received: from [199.232.76.173] (port=41589 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXIOO-0005db-2e for qemu-devel@nongnu.org; Wed, 11 Feb 2009 11:56:56 -0500 Received: from mx2.redhat.com ([66.187.237.31]:44912) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXION-0007RB-H1 for qemu-devel@nongnu.org; Wed, 11 Feb 2009 11:56:55 -0500 Message-ID: <49930353.7040100@redhat.com> Date: Wed, 11 Feb 2009 18:56:51 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] remove smaller slots if registering a bigger one 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> <49930130.5050409@siemens.com> In-Reply-To: <49930130.5050409@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Jan Kiszka wrote: >> 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. > Most of these mappings (at least in the PC world) are PCI mappings, no? In which case the PCI layer already tracks everything. There's an issue if the guest programs conflicting BARs. Currently qemu has a latest-wins policy, but that's not necessarily the right thing. -- error compiling committee.c: too many arguments to function