From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMjok-00037u-3W for qemu-devel@nongnu.org; Wed, 18 May 2011 12:41:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMjoj-0002Fh-33 for qemu-devel@nongnu.org; Wed, 18 May 2011 12:41:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28246) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMjoi-0002Fb-Ob for qemu-devel@nongnu.org; Wed, 18 May 2011 12:41:49 -0400 Message-ID: <4DD3F6C7.3020907@redhat.com> Date: Wed, 18 May 2011 19:41:43 +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> In-Reply-To: <4DD3F4D5.7020807@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 07:33 PM, Anthony Liguori wrote: > On 05/18/2011 10:23 AM, Avi Kivity wrote: >>> The tricky part is wiring this up efficiently for TCG, ie. in QEMU's >>> softmmu. I played with passing the issuing CPUState (or NULL for >>> devices) down the MMIO handler chain. Not totally beautiful as >>> decentralized dispatching was still required, but at least only >>> moderately invasive. Maybe your API allows for cleaning up the >>> management and dispatching part, need to rethink... >> >> My suggestion is opposite - have a different MemoryRegion for each (e.g. >> CPUState::memory). Then the TLBs will resolve to a different ram_addr_t >> for the same physical address, for the local APIC range. > > I don't understand the different ram_addr_t part. > The TLBs map a virtual address to a ram_addr_t. > The TLB should dispatch to a per-CPU dispatch table. The per-CPU > should dispatch almost everything to a global dispatch table. > > The global dispatch table is the chipset (Northbridge/Southbridge). > > The chipset can then dispatch to individual busses which can then > further dispatch as appropriate. > > 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. > 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. 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. -- error compiling committee.c: too many arguments to function