From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkAU-0003dQ-3v for qemu-devel@nongnu.org; Wed, 18 May 2011 13:04:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMkAS-0005xj-77 for qemu-devel@nongnu.org; Wed, 18 May 2011 13:04:18 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:53762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkAS-0005xR-4P for qemu-devel@nongnu.org; Wed, 18 May 2011 13:04:16 -0400 Received: by gyg4 with SMTP id 4so704309gyg.4 for ; Wed, 18 May 2011 10:04:15 -0700 (PDT) Message-ID: <4DD3FC0D.2070901@codemonkey.ws> Date: Wed, 18 May 2011 12:04:13 -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> <4DD3F4D5.7020807@codemonkey.ws> <4DD3F6C7.3020907@redhat.com> In-Reply-To: <4DD3F6C7.3020907@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 11:41 AM, Avi Kivity wrote: > 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. It actually maps virtual address to host virtual addresses. Virtual addresses that map to I/O memory never get stored in the TLB. 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. >> 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. >> 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? > 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. Regards, Anthony Liguori