From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMitA-0008WV-Or for qemu-devel@nongnu.org; Wed, 18 May 2011 11:42:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMit8-00017y-Ks for qemu-devel@nongnu.org; Wed, 18 May 2011 11:42:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7286) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMit8-00017i-Be for qemu-devel@nongnu.org; Wed, 18 May 2011 11:42:18 -0400 Message-ID: <4DD3E8D6.6090807@redhat.com> Date: Wed, 18 May 2011 18:42:14 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD3D236.90708@siemens.com> <4DD3D95E.2060105@redhat.com> <4DD3E1B3.3020405@siemens.com> <4DD3E47F.9060104@redhat.com> <4DD3E782.8090208@siemens.com> In-Reply-To: <4DD3E782.8090208@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel On 05/18/2011 06:36 PM, Jan Kiszka wrote: > > > > We need to head for the more hardware-like approach. What happens when > > you program overlapping BARs? I imagine the result is > > implementation-defined, but ends up with one region decoded in > > preference to the other. There is simply no way to reject an > > overlapping mapping. > > But there is also now simple way to allow them. At least not without > exposing control about their ordering AND allowing to hook up managing > code (e.g. of the PCI bridge or the chipset) that controls registrations. What about memory_region_add_subregion(..., int priority) as I suggested in another message? Regarding bridges, every registration request flows through them so they already have full control. > ... > >> See [1]: We really need to get rid of slot management on > >> CPUPhysMemoryClient side. Your API provides a perfect opportunity to > >> establish the infrastructure of slot tracking at a central place. We can > >> then switch from reporting cpu_registering_memory events to reporting > >> coalesced changes to slots, those slot that also the core uses. So a new > >> CPUPhysMemoryClient API needs to be considered in this API change as > >> well - or we change twice in the end. > > > > The kvm memory slots (and hopefully future qemu memory slots) are a > > flattened view of the MemoryRegion tree. There is no 1:1 mapping. > > We need a flatted view of your memory regions during runtime as well. No > major difference here. If we share that view with PhysMemClients, they > can drop most of their creative slot tracking algorithms, focusing on > the real differences. We'll definitely have a flattened view (phys_desc is such a flattened view, hopefully we'll have a better one). We can basically run a tree walk on each change, emitting ranges in order and sending them to PhysMemClients. -- error compiling committee.c: too many arguments to function