From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMjgf-0007op-IN for qemu-devel@nongnu.org; Wed, 18 May 2011 12:33:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMjge-00018q-Hu for qemu-devel@nongnu.org; Wed, 18 May 2011 12:33:29 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:32880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMjge-00018e-Bw for qemu-devel@nongnu.org; Wed, 18 May 2011 12:33:28 -0400 Received: by yib19 with SMTP id 19so692434yib.4 for ; Wed, 18 May 2011 09:33:27 -0700 (PDT) Message-ID: <4DD3F4D5.7020807@codemonkey.ws> Date: Wed, 18 May 2011 11:33:25 -0500 From: Anthony Liguori 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> In-Reply-To: <4DD3E47F.9060104@redhat.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: Avi Kivity Cc: Jan Kiszka , qemu-devel 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 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. 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. Regards, Anthony Liguori