From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkJw-0007ac-CG for qemu-devel@nongnu.org; Wed, 18 May 2011 13:14:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMkJv-0007Yp-B5 for qemu-devel@nongnu.org; Wed, 18 May 2011 13:14:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkJv-0007Yh-0E for qemu-devel@nongnu.org; Wed, 18 May 2011 13:14:03 -0400 Message-ID: <4DD3FE55.7020802@redhat.com> Date: Wed, 18 May 2011 20:13:57 +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> <4DD3F4D5.7020807@codemonkey.ws> <4DD3F6C7.3020907@redhat.com> <4DD3FC0D.2070901@codemonkey.ws> In-Reply-To: <4DD3FC0D.2070901@codemonkey.ws> 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: Anthony Liguori Cc: Jan Kiszka , qemu-devel On 05/18/2011 08:04 PM, Anthony Liguori wrote: >> The TLBs map a virtual address to a ram_addr_t. > > > It actually maps virtual address to host virtual addresses. Virtual > addresses that map to I/O memory never get stored in the TLB. They are stored. Look at glue(io_read, SUFFIX) and its caller for example. > > You don't need separate I/O registration addresses in order to do > per-CPU dispatch provided that you route the dispatch routines through > the CPUs first. Right, but you pay for an extra lookup which always fails. >>> Overlapping regions can be handled differently at each level. For >>> instance, if a PCI device registers an IO region to the same location >>> as the APIC, the APIC always wins because the PCI bus will never see >>> the access. >>> >> >> That's inefficient, since you always have to traverse the hierarchy. > > Is efficiency really a problem here? Besides, I don't think that's > really correct. You're adding at most 2-3 extra function pointer > invocations. I don't think you can really call that inefficient. Well, you'll need something special for SMM as well. Per-cpu memory map solves all that neatly. > >>> You cannot do this properly with a single dispatch table because the >>> behavior depends on where in the hierarchy the I/O is being handled. >> >> You can. When you have a TLB miss, you walk the memory hierarchy (which >> is per-cpu) and end up with a ram_addr_t which is stowed in the TLB >> entry. > > I think we're overloading the term TLB. Are you referring to > l1_phys_map as the TLB because I thought Jan was referring to the > actual emulated TLB that TCG uses? env->iotlb. For some reason I though this was folded into enc->tlb_table, but it isn't (should it be? saves a lookup). > >> Further accesses dispatch via this ram_addr_t, without taking the >> cpu into consideration (the TLB is, after all, already per-cpu). >> >> Since each APIC will have its own ram_addr_t, we don't need per-cpu >> dispatch. > > You need to have per-CPU l1_phys_maps which would result in quite a > lot of additional memory overhead. This is predicated on a better lookup method, yes. -- error compiling committee.c: too many arguments to function