From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMEUx-0007q9-Rr for qemu-devel@nongnu.org; Thu, 11 Oct 2012 04:52:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMEUt-0001Vh-Oj for qemu-devel@nongnu.org; Thu, 11 Oct 2012 04:52:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMEUt-0001Va-FS for qemu-devel@nongnu.org; Thu, 11 Oct 2012 04:52:03 -0400 Message-ID: <507688A9.5060506@redhat.com> Date: Thu, 11 Oct 2012 10:51:53 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1349800368-15228-1-git-send-email-avi@redhat.com> <1349800368-15228-20-git-send-email-avi@redhat.com> <507683F2.9010605@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 19/23] memory: per-AddressSpace dispatch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Blue Swirl , Paolo Bonzini , qemu-devel@nongnu.org, Anthony Liguori , "Michael S. Tsirkin" On 10/11/2012 10:45 AM, liu ping fan wrote: > On Thu, Oct 11, 2012 at 4:31 PM, Avi Kivity wrote: >> On 10/11/2012 05:38 AM, liu ping fan wrote: >>>> >>>> +void address_space_init_dispatch(AddressSpace *as) >>>> +{ >>>> + AddressSpaceDispatch *d = g_new(AddressSpaceDispatch, 1); >>>> + >>>> + d->phys_map = (PhysPageEntry) { .ptr = PHYS_MAP_NODE_NIL, .is_leaf = 0 }; >>>> + d->listener = (MemoryListener) { >>>> + .begin = mem_begin, >>>> + .region_add = mem_add, >>> >>> mem_add() has the fixed mapping relationship between addr(in >>> system_memory) and mr. If we want to fold lookup logic of iommu into >>> radix-tree, it will need external behavior. So I think >>> address_space_init_dispatch(as) should be >>> address_space_init_dispatch(as, listener). >> >> This is per address space, it's not tied to system_memory(). >> > Then, where do we implement iommu translation logic? Above the radix-tree? I will post patches soon. Basically each iommu does the translation, then uses another radix tree to continue the dispatch. Eventually we reach the bottom. We can't use the radix tree to resolve iommu translations because they change dynamically and are resolved on demand, while the radix tree is read-mostly and prepared beforehand. -- error compiling committee.c: too many arguments to function