From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMjO7-00020b-MY for qemu-devel@nongnu.org; Wed, 18 May 2011 12:14:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMjO6-0006Tf-I9 for qemu-devel@nongnu.org; Wed, 18 May 2011 12:14:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10705) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMjO6-0006Tb-5g for qemu-devel@nongnu.org; Wed, 18 May 2011 12:14:18 -0400 Message-ID: <4DD3F055.6000905@redhat.com> Date: Wed, 18 May 2011 19:14:13 +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> <4DD3E8D6.6090807@redhat.com> <4DD3ED22.6080005@siemens.com> In-Reply-To: <4DD3ED22.6080005@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 07:00 PM, Jan Kiszka wrote: > On 2011-05-18 17:42, Avi Kivity wrote: > > 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? > > That's fine, but also requires a change how, or better where devices > register their regions. Lost you - please elaborate. > > > > Regarding bridges, every registration request flows through them so they > > already have full control. > > Not everything is PCI, we also have ISA e.g. If we were able to route > such requests also through a hierarchy of abstract bridges, then even > better. Yes, it's a tree of nested MemoryRegions. > > We'll definitely have a flattened view (phys_desc is such a flattened > > view, hopefully we'll have a better one). > > phys_desc is not exportable. If we try (and we do from time to time...), > we end up with more slots than clients like kvm will ever be able to handle. If we coalesce ajacent phys_descs we end up with a minimal representation. Of course that's not the most efficient implementation (a tree walk is better). > > > > We can basically run a tree walk on each change, emitting ranges in > > order and sending them to PhysMemClients. > > I'm specifically thinking of fully trackable slot updates. The clients > should not have to maintain the flat layout. They should just receive > updates in the form of slot X added/modified/removed. For now, this > magic happens multiple times in the clients, and that is very bad. Slots don't have any meaning. You can have a RAM region which is overlaid by a smaller mmio region -> the RAM slot is split into two. We should just send clients a list of ranges, and they can associate them with slots themselves. > Given that not only memory clients need that view but that ever TLB miss > (in TCG mode) requires to identify the effective slot as well, it might > be worth preparing a runtime structure at registration time that > supports this efficiently - but this time without wasting memory. Yes. Won't be easy though. Perhaps a perfect hash table for small regions and a sorted-by-size array for large regions. -- error compiling committee.c: too many arguments to function