From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMjum-0005xv-Eo for qemu-devel@nongnu.org; Wed, 18 May 2011 12:48:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMjul-0003OT-Di for qemu-devel@nongnu.org; Wed, 18 May 2011 12:48:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMjul-0003OM-6P for qemu-devel@nongnu.org; Wed, 18 May 2011 12:48:03 -0400 Message-ID: <4DD3F83E.4090700@redhat.com> Date: Wed, 18 May 2011 19:47:58 +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> <4DD3F055.6000905@redhat.com> <4DD3F626.7060500@siemens.com> In-Reply-To: <4DD3F626.7060500@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:39 PM, Jan Kiszka wrote: > >> > >> That's fine, but also requires a change how, or better where devices > >> register their regions. > > > > Lost you - please elaborate. > > Devices currently register against the core, that's nothing your API > automatically changes (though it lays the foundation to do so). But > devices should rather register against the corresponding bus. The bus > (ie. the device managing it) could then forward the request, stick it > into a subregion, or have it for dinner. Yes. We'd change pci_register_bar() to accept a MemoryRegion. > However, we are yet in troubles if we want to change that because > devices can only be on one bus - at least so far. Nothing prohibits a device from calling pci_register_bar() for one region and some other API for another. btw, another motivation for this API is for dual ISA/PCI devices. This way most of the work is bus agnostic, with just the actual registration being bus specific. > ... > >> 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. > > And that association logic should be as simple as matching a unique > range ID against an existing slot (for updates and deletions) or adding > a new slot for a new range and storing the ID. Anything else will not > allow to simplify the existing code bases noticeably. That's my point. We won't have a natural ID. But I'll see if I can have a library calculate the minimum difference between the previous layout and current layout. Should not be too hard. > > > >> 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. > > Keep in mind that TCG will be our benchmark for these changes as it > requires much more accesses than KVM. We must avoid designing the new > infrastructure with exclusive focus on KVM (and also x86). I think TCG will not be affected much since it stores ram_addr_t's in its TLBs, so the lookup is only done on a TLB miss. In fact there's a change for a slight win since we'll probably be able to keep the new layout in cache compared to phys_desc. -- error compiling committee.c: too many arguments to function