qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 19/23] memory: per-AddressSpace dispatch


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v3 19/23] memory: per-AddressSpace dispatch
Date: Thu, 11 Oct 2012 10:51:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

On 10/11/2012 10:45 AM, liu ping fan wrote:
> On Thu, Oct 11, 2012 at 4:31 PM, Avi Kivity <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]